John Maddock wrote:
#ifdef __BORLANDC__
# pragma option push -a8 -b -Vx -Ve -pc -w-8027
#endif
// code here
#ifdef __BORLANDC__
# pragma option pop
#endif
We should standardize this boost-wide really in some kind of prefix/suffix
header.
Here is the discussion (it cropped up with signals lib
John Torjo wrote:
I agree this would be nice. Of course, I think this will need to fail
compilation if the resolution doesn't support nanoseconds.
Not really. If lets say the fractional_seconds are milliseconds, then you
should return ticks() * 1000 (I think)
I think it should fail. Otherwise yo
Beman Dawes wrote:
In the meantime, you might want to try running the regression tests
using any compiler you have at hand. While we are doing much better with
docs, etc., running the tests still take a bit of getting used to.
I plan to do that, I'm currently using BCB6 so it would be a good
st
Thanks, its gone now (I managed an update an hour or so ago).
Cheers
Russell
Beman Dawes wrote:
At 02:48 AM 8/13/2003, Russell Hind wrote:
>This lock has been there since I tried updating boost last night (about
>8 hours ago).
Please report stale locks to SourceForge support. They a
This lock has been there since I tried updating boost last night (about
8 hours ago).
Thanks
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peter Dimov wrote:
To make out-of-line libraries "plug and play" we may have to prefix/suffix
all* inline libraries as well, making their users pay for something they do
not need.
* Under the assumption that they are potential future dependencies.
I understand this (and it was because signals reli
Beman Dawes wrote:
At 12:53 PM 8/6/2003, Russell Hind wrote:
Perhaps coordinate with John Maddock? He is really our config header
expert.
So John, would you be interested in trying to get this sorted out for
the next release? As I have said, I currenly only use BCB, and so can't
offer
Beman Dawes wrote:
I'd like to be sure that some Booster signs up for this beta and starts
running the Boost regression tests against it. And then follows up with
bug reports to Borland as needed. Any bugs fixed in the compiler before
it ships are bugs Boosters don't have to cope with later.
An
This is just what I would like to see in boost. I have created a
duplicate set of headers for boost (same names, same structure but in
boost_wrappers which do this and include the original header between the
push and pop). We had a discussion about this a while back and I am all
for it, but p
Bohdan wrote:
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message
Do you mean link of incompatible library problems ?
If so ... as mentioned this is problem of boost build system
and it will be finally solved. Look at boost::regex, it doesn't have
such problems for compilers supporting "#pragma c
# if BOOST_WORKAROUND( __BORLANDC__, >= 0x0560 )
I would just like to point out that if _USE_OLD_RW_STL is defined, BCB6
uses the roguewave STL from BCB5 and so doesn't have this _STL/std::
conflict. So it may be worth introducing that into the #if somehow.
(I don't define this because I prefer
John Maddock wrote:
I'm wondering how complicated to make this - one option would be to do
something a little like the config system does and have:
#ifdef BOOST_ABI_INCLUDE
#include BOOST_ABI_PREFIX
#endif
// code...
#ifdef BOOST_ABI_INCLUDE
#include BOOST_ABI_SUFFIX
#endif
Some of those warnings
Beman Dawes wrote:
I don't think people were against the idea of solving the problem, but
rather there is a need for a unified prefix/suffix header solution such
as John is suggesting. Developers need a "canned" solution; they can't
be asked to code #ifdefs and pragmas for compilers they know no
Peter Dimov wrote:
The main problem with shared_ptr 1.30.x and below is that the single- and
multithreaded versions are incompatible. The CVS version is now binary
compatible on Windows, so 1.31 will "work" across different threading
models; still, the correct default for Borland should probably be
E. Gladyshev wrote:
IMO, I should be able to just use the library w/o this
kind of workarounds. It is hard to debug these .lib/.h
conflict issues.
Why build the .lib at all? Why not just add the signals source file to
your project? I did this for a while with thread and signals. I've
since now
E. Gladyshev wrote:
Thanks for taking a look at the problem. IMO,
distributing objects between inlines and DLL functions
is not a very good idea. The classic example is:
It can cause problems but if you are aware of it, then you can work
around it quite easily. Part of the reason in speed. Som
E. Gladyshev wrote:
Have you built the signals library multi-threaded or
single threaded and
Whatever the default build is.
Single threaded.
The application is set to use multi-thread run-time
libraries and MFC.DLL.
Not seen this specific one, the most common problem
I saw was a hang so
it
E. Gladyshev wrote:
Anybody had problems with boost::signal? The following
sample code crashes on my Win2k/VC++6 system.
Have you built the signals library multi-threaded or single threaded and
are you building an application of the same sort? This seems to be a
common source of problems with t
John Torjo wrote:
time_iterator it( start, days(1) + hours( 12)) instead of:
Why not days(1.5) then? That would be even easier, wouldn't it?
Cheers
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peter Dimov wrote:
This looks like a motivating example for scoped_unlock. :-)
That would definitely be useful. In places I have made my own
scoped_unlock (well, just called unlocker) but I haven't re-used it
everywhere yet!.
Cheers
Russell
___
Unsu
David Abrahams wrote:
That sounds like what I remember Bill telling me.
but scoped locks don't tend to be shared. The mutex is, but the actual
lock isn't intended to be. Certainly not accross threads, so there
shouldn't be race conditions in scoped_lock.
Russell
_
Jon Biggar wrote:
Russell Hind wrote:
Ok, but what happens if locking an already locked mutex where
undefined behaviour? This isn't this the same as the smart_ptr case?
Who knows how the actual implementation is on all the platforms, or
future platforms?
Um, wasn't the questio
Beman Dawes wrote:
Seems like we are very close to being ready to do a 1.31.0 release. One
new library has been added since 1.30.0, at least two libraries have had
interface upgrades, and a large number of bugs have been fixed in
numerous libraries.
How about 1 or maybe more betas of 1.31.0 (li
You need to pass a separator into the tokenizer that only separates on
',' (i'm not sure if this code compiles, but you get the idea
std::string Pages("2,3,5-7");
char_separator CommaSep(",");
tokenizer > Tokenizer(Pages,CommaSep);
This will split it up into
2
3
5-7
You will then nee
Jeff Garland wrote:
In date-time there are several 'to_string' functions that provide
different ouput formats so a single 'str()' method isn't going
to be enough. As for c_str(), you can use this once you have
std::string. From my view there is no point in trying to force
fit this functionality
It's only minor:
But boost::filesystem and boost::date_time have string conversion
methods such as
string()
native_file_string()
to_simple_string()
where as boost::format (and also stringstreams in the STL) have
str()
I don't know about the other libraries? Is there a standard for this in
bo
Philippe A. Bouchard wrote:
lock()...
if (thread() == f1 || thread() == f2)
{
thread()..(whatever casts)...m_list;
}
unlock()...
// I think the only way to do this is by mapping the thread's id
// with the object's address
Look at the thread_dev branch of boost::thread in the CVS. There are
many changes (including priority) that haven't been finalised yet.
Hopefully they will make it into 1.31.0 whenever that will be released.
Cheers
Russell
Maxim Egorushkin wrote:
Hello,
I've been missing a feature in the t
Tim Russell wrote:
boost::filesystem::path p;
p = boost::filesystem::path(" .txt"); .// Three spaces
Have you tried
p = boost::filesystem::path(" .txt", boost::filesystem::native);
as this is how I have to construct paths on Windows because of the \
separater. Maybe this will work for you
Daniel Frey wrote:
Sure. But still compose.hpp is in itself incomplete. And it completes
the standard's parts on function objects so I think it might be
desirable to supply compose_f_gxy_hxy. If we take bind into account
here, we could just as well remove compose.hpp completly, couldn't we?
Or
Vladimir Prus wrote:
I have a few comments regarding the tokenizer library.
1. The documentation says that char_delimiters_separator is default parameter
to 'tokenizer' template, and at the same time says that
'char_delimiters_separator' is deprecated. I think that's confusing and
default param
Trevor Taylor wrote:
Who? Me?
I think Peter meant Alexander
Cheers
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AFAICT, there are places this needs changing so as you come accross
them, I would just post to this group so someone with access can change
it in the CVS for the next release.
Maybe a __BORLANDC__LATEST could be defined in the compiler config
headers rather than embedding version numbers all ov
Roland Richter wrote:
It seems to be easy to synchronize variables - see the
very minimalistic draft below. But what about synchronized
class methods etc.?
Using the scoped_lock on a mutex (like you have done in the example),
will work for the entire method. The lock isn't freed until the me
Darren Cook wrote:
In my own assert library I added options for logging, but in the end
never used that and always had it throw an exception. This is nice for
two reasons:
1. MFC debugger catches it and allows me to go back up the call stack
to where the assert happened. (I'm still struggling
Vladimir Prus wrote:
b) versioning at the class level
I implemented a binary serialisation library at my previous work place
that was very similar to what has been described here.
As for versioning, we left it up to the class. But implemented it in
all classes. All classes stored a version n
Johan Nilsson wrote:
Perhaps, but one should consider that GetSystemTime promises 1ms resolution
and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises
250ns resolution).
The Platform SDK states that the tickcount (GetTickCount) is updated
every 10ms on NT3.51 and hight so I guess
Johan Nilsson wrote:
Yes, but why not have both on all platforms?
I suppose another solution is to have secs_clock, millisecs_clock on
windows, all three on another platform that supports microseconds, and
then a typedef of something like highprescision_clock which on windows
will be a millisec
Johan Nilsson wrote:
Yes, but why not have both on all platforms?
It would make using it cross-platform easier, but you aren't actually
getting microsecond information under windows, so if your program relies
on that detail, it won't work correctly under windows anyway, so you
must make your pr
Johan Nilsson 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.
Yes and yes. But the former (using them to get an actual date/time with a
_low_ overhead) is ... well ... interesting ;-)
Ho
Johan Nilsson wrote:
I might be a bit off here (coming in late into the discussion), but I'd
prefer consistency in my code; using microsec_clock for both Windows and
Unix code - even if the real 'resolution' is dependent of the system time
updates on the Win platforms.
That is an option, but if a m
William E. Kempf wrote:
You can do this simply by placing the applications in seperate directories
and keeping the proper DLL version alongside the executable. Not
necessarily the ideal solution, but it's the easiest way to solve "DLL
Hell".
The reason I've not done this (and want to go to the 've
William E. Kempf wrote:
Theoretically at least, I don't see why this would cause a problem. You
intentionally leak, but the leak is benign since it occurs only right
before the application exits. But most users won't code this way, nor do
I want to have to deal with the support requests/questions
I'd been wondering this, and heard about TLS issues. The issues are
only on Windows it appears. Search for the thread
"Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on 18/02/2003
Specifically, the many posts by William Kempf and Edward Diener discuss
the problems on windows wi
Mark Blewett wrote:
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.
FYI: From Mic
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
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* ar
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 take
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
_
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
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
addi
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_
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_ti
Alisdair Meredith wrote:
Russell Hind wrote:
I had the same problem with C++Builder 6 when first using the filesystem
library. The default builds for filesystem are single threaded. If
your application is multi-threaded, then you need to re-build the
filesystem library with multi-threading (it
While we're on the subject of broken links, the link to date_time change
history doesn't work from the boost home page
http://www.boost.org/libs/date_time/doc/Changes.html
Cheers
Russell
Rozental, Gennadiy wrote:
My point is: shouldn't we check it before release, so that library authors
will t
Alisdair Meredith wrote:
Beman Dawes wrote:
There just isn't any time left. See "OK to tag for release?" message just
posted.
Sorry,
The line has to be drawn somewhere, and it is human nature to wish we
were the other side
I will be able to test properly with the new BCB patch myself next
Samuel Krempp wrote:
Le mer 19/03/2003 à 14:27, Russell Hind a écrit :
and this _USE_OLD_RW_STL macro is then an adequate mean to detect such
cases ? if so, I could disable the workaround, depending to this macro.
but not right before the release.
My take on this is:
BCB5 (0x550 to 0x551
Alisdair Meredith wrote:
Russell Hind wrote:
Does anybody know if this needs fixing, or is it my mistake. If it
needs fixing, is someone able to do it before 1.30.0 is released?
Yes, I think it needs fixing!
I think simply dropping the separate test for 0x0561 is easiest, given
the Kylix test
Trevor Taylor wrote:
As a software user I am frequently frustrated by "an error occurred"
like failure messages. As a developer I know that the software *knows*
exactly what failed, why, and exactly what it was doing at the time, but
doesn't pass any of this information on.
Recently I developed som
Does anybody know if this needs fixing, or is it my mistake. If it
needs fixing, is someone able to do it before 1.30.0 is released?
Thanks
Russell
Russell Hind wrote:
Sorry about last post, Mozilla decided to send when I tried to paste
stuff into the message (?). Strange, but probably
John Maddock wrote:
It looks more likely that you actually compiled with Builder 6, as that
ships with (and uses) that lib.
I ran into this problem. Builder 6 puts itself at the head of the path,
so when you run make (for building regex), I ended up building with BCB6
make, and then tried linkin
Sorry about last post, Mozilla decided to send when I tried to paste
stuff into the message (?). Strange, but probably finger trouble. Here
goes again:
I have just tried boost::format with C++Builder 6 Update 4 and works
fine (simple test), but have to
#define BOOST_BAD_ISDIGIT
Looking in f
I have just tried boost::format with C++Builder 6 Update 4, and have to
either
#define BOOST_BAD_ISDIGIT
or
#define _USE_OLD_RW_STL
Looking in format.hpp (line 43) there is
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi
I see that boost::thread has moved to a dll implementation (win32) in
1.30.0-b1. I have modified the JamFile for boost:thread so it builds
the lib as well as the dll. Default build be made to do both, rather
than just the dll? Or is boost moving to dll implementation only for
all libraries?
Just a quick question: Are the changes made on the thread_dev branch
for the thread library going to make it into the 1.30.0 release or are
they being held back for a future release?
Thanks
Russell
___
Unsubscribe & other changes: http://lists.boost
FYI I've submitted it as QC#3629
Russell
Paul Mensonides wrote:
Russell Hind wrote:
Sorry to say that the output is now incorrect. A2 instead of A 2.
Checking the preprocessor output for this gives
/* Unit1.cpp 9: */int main() {
/* Unit1.cpp 10: */std::cout << "A 2" &l
since I thought that bcc32 was
just supposed to call cpp32 for the pre-processing. I can submit this
as a bug to Borlands QualityCentral if you like (but don't hold your
breath).
Cheers
Russell
Paul Mensonides wrote:
Russell Hind wrote:
#define A() 1
#define B(m) m 2
B(A)
I've ru
Paul Mensonides wrote:
Beman Dawes wrote:
#define A() 1
#define B(m) m 2
B(A)
I've run the above through the preprocessor and heres the output
/* Unit1.cpp 1: */
/* Unit1.cpp 2: */
/* Unit1.cpp 3: */
/* Unit1.cpp 4: */A 2
Tested using the preprocess option with BCB6Pro Update 4. This looks
lik
Is yield intended to always yield to another thread if one can run?
Because the code for yield is
void thread::yield()
{
#if defined(BOOST_HAS_WINTHREADS)
Sleep(0);
#elif defined(BOOST_HAS_PTHREADS)
# if defined(BOOST_HAS_SCHED_YIELD)
int res = 0;
res = sched_yield();
assert(re
69 matches
Mail list logo
