Matthew Towler <[EMAIL PROTECTED]> writes:
> I have been attempting to build boost 1.30.2 for a number of platforms.
>
> I also wish to generate the html testsuite output for several reasons
We use python script to run our tests on Win32 - I can send it to you,
although it has some very specific
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> Point taken.
> There's no need to argue anymore.
> I guess significantly more feedback will weight the balance.
>
> Thanks for all your comments!
> It might look the other way around but they were very helpful.
Bottom line is, and most importantly,
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>
> > You did sell the idea that it can be a union, but I held to the idea that
> > it can just as well be considered as *REALLY REALLY REALLY*
> > nothing else but a co
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> You did sell the idea that it can be a union, but I held to the idea that
> it can just as well be considered as *REALLY REALLY REALLY*
> nothing else but a container that has a T or is empty.
>
> I agree there is nothing wrong with the union model,
> From: Fernando Cacciola [mailto:[EMAIL PROTECTED]
>
> Mat Marcus <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > Those who answer no to the above question may
> > prefer to write code that uniformly handles T and optional.
> >
> I doubt such uniformity can be implemented
--On Tuesday, September 02, 2003 10:48 PM -0300 Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
[snip]
For this reason, and for the fact that I have some upcoming
deadlines at work, I'll summarize what I see and where I stand now,
then I'll step back a bit for a while.
I hope you come back later
Mat Marcus <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> [snip]
> Here's a question that tries to get to the crux of the pointer-like
> interface matter. Should T* and optional both be models of a
> pointer-like syntactic concept?
>
pointers, iterators and optional are indeed mode
Joel de Guzman <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Mat Marcus <[EMAIL PROTECTED]> wrote:
> > --On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Joel de Guzman <[EMAIL PROTECTED]> wrote in message
> >>> One can think of a
Mat Marcus <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> --On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara
> <[EMAIL PROTECTED]> wrote: [snip]
>
> > As a final aside, I think much of this thread is degenerating into
> > Parkinson's Bicycle Shed[*], with respect to "is it
Daniel Frey <[EMAIL PROTECTED]> writes:
> Sorry, my fault. tie_example.cpp no longer exists, as 'tie' no longer
> lives in 'utility'. Can you please remove the reference from the
> test-file?
Sure.
> A last question to the
> build-wizards: Would it make sense to make the build system continue
>
Lambda's v cool but it tends not to play fair when promoted to global scope
and lambda::_1 just doesn't look right ;-)
Would be nice to solve the conflicts with boost::bind and lambda::bind.
Also there is, at least, a conflict with _1 between spirit and lambda that
has bitten me, perhaps others...
I see that there is some special code in type_with_alignment for Borland C++,
partly because it is broken and partly because we can do a better job using
compiler-specific features.
Why not do the same for other compilers? For instance, on GCC:
template
struct alignment_of
{ BOOST_STATIC_CO
Where is this documented, and what is "nano" in the table entry below?
static boost::date_time::time_resolutions resolution()
Describes the resolution capability of the time_duration class.
time_duration::resolution() --> nano
--
Dave Abrahams
Boost Consulting
www.boost-c
The "fractional seconds" concept is undocumented. My guess it's
something like:
x.fractional_seconds() == x.ticks() % seconds(1).ticks()
This needs to be nailed down.
Also, the assymetry of those nice Construction by Count factories down
to nanosec(x) with the accessors which only includ
On Tuesday 02 September 2003 05:01 pm, David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
> > Maybe adding struct { double x; } would be enough?
>
> I think it would be safer to add struct { double T; } for each T in
> the list of types, just in case.
I agree. I've checked in the fo
Suppose I want to know how many minutes there are in a particular
duration d? My intuition says:
d / minutes(1)
But there's no such operator. Why not?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other chan
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> > T* _p;
>
> Leading underscores are a no-no.
I didn't see it in boost naming convention docs.
Have I missed it?
Some STL implmentations use leading underscores for members.
Eugene
__
Do you Yahoo!?
Ya
> From: David Abrahams [mailto:[EMAIL PROTECTED]
> Subject: [boost] date_time naming
>
> I'm just getting started with the date_time library, and I
> think I'm gonna like it. I have some quibbles with the
> naming choices though (shocking! me of all people!) For
> example, why is the nested
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> > 3. If your class is using STL containers, use boost::memory::allocator
> >adapter (see bellow).
>
> Why not just use std::allocator?
Because boost::memory::allocator will use UserAllocator under the covers.
So if you customized UserAll
On Tuesday 02 September 2003 04:58 pm, Misha Bergal wrote:
> Douglas Gregor <[EMAIL PROTECTED]> writes:
> > http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/
> >
> > You can build local copies of the documentation with BBv2 once you've
> > read it
>
> Thanks. It worked. We will be publi
David Abrahams wrote:
> Gregory Colvin <[EMAIL PROTECTED]> writes:
>
>>> Also, if shared_ptr only needs to allocate at construction time (I'm
>>> not sure of this) we can avoid storing the allocator at all.
>>
>> Then how to deallocate?
>
> Using the custom deleter?
The deleter takes care of the p
On Tuesday, Sep 2, 2003, at 15:00 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
Whi
Misha Bergal wrote:
The metacomm regression tests run failed last night because of the
following bjam failure:
boost-test(RUN) "iterators" : "libs\multi_array\test\iterators.cpp"
boost-test(RUN) "compare" : "libs\multi_array\test\compare.cpp"
boost-test(RUN) "access" : "libs\multi_array\test\access
--On Tuesday, September 02, 2003 3:32 PM -0400 Douglas Paul Gregor
<[EMAIL PROTECTED]> wrote:
On Tue, 2 Sep 2003, Mat Marcus wrote:
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
<[EMAIL PROTECTED]> wrote:
> I suspect they are both '4', but that leaves me even more confused
> as
"Pavel Vozenilek" <[EMAIL PROTECTED]> writes:
>> > 14. Btw, isn't cb_iterator::operator[]() added by mistake? I have
>> > never seen such an operation for iterator. No, iterators do have
>> > this operator.
>>
> Oops, newer used before :-o
Is there some reason you're defining your own iterators
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> Douglas Paul Gregor wrote:
>
> [...]
>
>>> struct A {
>>> double d;
>>> int i;
>>> };
>
> [...]
>
>> Are there any other crazy rules like this that you know of? We could
>> just add "struct A" from above to the list of types, or if there is a
>> CodeWarr
On Tuesday, Sep 2, 2003, at 13:18 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
Yep. I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new
Douglas Gregor <[EMAIL PROTECTED]> writes:
> http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/
>
> You can build local copies of the documentation with BBv2 once you've read it
Thanks. It worked. We will be publishing HTML docs starting with this night's run.
--
Misha Bergal
MetaCo
Gregory Colvin <[EMAIL PROTECTED]> writes:
>> Also, if shared_ptr only needs to allocate at construction time (I'm
>> not sure of this) we can avoid storing the allocator at all.
>
> Then how to deallocate?
Using the custom deleter?
>>> I'm reeling from the implication that the following is unde
The metacomm regression tests run failed last night because of the
following bjam failure:
boost-test(RUN) "iterators" : "libs\multi_array\test\iterators.cpp"
boost-test(RUN) "compare" : "libs\multi_array\test\compare.cpp"
boost-test(RUN) "access" : "libs\multi_array\test\access.cpp"
boost-test(R
I'm just getting started with the date_time library, and I think I'm
gonna like it. I have some quibbles with the naming choices though
(shocking! me of all people!) For example, why is the nested
namespace called posix_time instead of, simply, posix? Once you're in
a date_time context it seems
Douglas Paul Gregor wrote:
[...]
>> struct A {
>> double d;
>> int i;
>> };
[...]
> Are there any other crazy rules like this that you know of? We could
> just add "struct A" from above to the list of types, or if there is a
> CodeWarrior-specific extension (e.g., something like "#pragma pack"
On Tue, 2 Sep 2003, Mat Marcus wrote:
> --On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
> <[EMAIL PROTECTED]> wrote:
> > I suspect they are both '4', but that leaves me even more confused
> > as to why the alignment of std::pair would be 8
> > (and how to get a POD type with alignme
On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams
wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
So you would rather use this than use construct?
template T*
On Tuesday, Sep 2, 2003, at 13:00 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Then again, the Dinkumware implementation
dutifully calls construct and destroy, paying (and forcing me to pay)
the abstraction penalty
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> Yep. I still think UserAllocator is a good default, and that where it
> doesn't suffice there is some value to playing nicely with STL.
>
> So even when we come up with some beautiful new thing to do the
> allocation job better, we will still need
Hello Jano,
> > 5. Borland C++ Builder 6.4 doesn't allow to bring
> >operator[] via using.
...
>
> What about just overriding operator[] for all compilers? (With the note
that some
> compilers doesn't support using for operators.)
>
Incentive for vendows to blush and fix the bug? AFAICS Borlan
Gregory Colvin wrote:
> On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
>
>> Then again, the Dinkumware implementation
>> dutifully calls construct and destroy, paying (and forcing me to pay)
>> the abstraction penalty price... so maybe I'm wrong, and
>> construct/destroy are
--On Tuesday, September 02, 2003 2:00 PM -0400 Douglas Gregor
<[EMAIL PROTECTED]> wrote:
On Tuesday 02 September 2003 01:36 pm, Mat Marcus wrote:
We're trying to use optional from 1.30.0 (sorry legal hasn't
approved our use of 1.30.2 yet). However on one compiler
(Metrowerks 8.3 PPC CFM) we're
Gregory Colvin <[EMAIL PROTECTED]> writes:
> On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>>
>>> So you would rather use this than use construct?
>>>
>>>template T* addressof(T& v)
>>>{
>>> return reinterpret_ca
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always assumed
"Iain K. Hanson" <[EMAIL PROTECTED]> writes:
>> But is this a good design? It certainly isn't the only possible one.
>> (Making all the code depend upon the definitions of both Network_err and
>> File_system_err - which no doubt drags other stuff into the translation unit
>> - isn't a design choi
On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
...
I think you're missing my point. There's no reason that a stateful
allocator should have access to the s
Gregory Colvin wrote:
>
> You are assuming that there was no good reason to allow an allocator
> to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always assumed that
construct/destroy/pointer are a "but someone might need t
--- David Abrahams <[EMAIL PROTECTED]> wrote:
[...]
> > I think construct/destroy can be implemented as non-customizable
> > static functions in boost just for convinence.
>
> I think the word "static" is not what you meant, and is what led me
> to challenge the suggestion.
I used word 'static
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
I think part of my point was that *nobody* needs what they offer,
On Tuesday 02 September 2003 01:36 pm, Mat Marcus wrote:
> We're trying to use optional from 1.30.0 (sorry legal hasn't approved
> our use of 1.30.2 yet). However on one compiler (Metrowerks 8.3 PPC
> CFM) we're getting static asserts from the alignment calculation
> metafunctions. Below is an abst
On Tue, 2003-09-02 at 18:06, [EMAIL PROTECTED] wrote:
> > -Original Message-
> > From: David Abrahams [mailto:[EMAIL PROTECTED]
> >
> > Alan, did you read
> > http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628
> > ??
>
> I have, but (leaving aside the argument from authority) the
"E. Gladyshev" <[EMAIL PROTECTED]> writes:
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
> [...]
>> Just how do you propose to prevent people from writing their own
>> construct/destroy functions? And if they write an allocator from
>> scratch, but *don't* provide construct/destroy manually, wh
[EMAIL PROTECTED] writes:
>> -Original Message-
>> From: David Abrahams [mailto:[EMAIL PROTECTED]
>>
>> Alan, did you read
>> http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628
>> ??
>
> I have, but (leaving aside the argument from authority) the example is too
> sketchy convinci
Gregory Colvin <[EMAIL PROTECTED]> writes:
> On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
>
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>> ...
>>> Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type para
We're trying to use optional from 1.30.0 (sorry legal hasn't approved
our use of 1.30.2 yet). However on one compiler (Metrowerks 8.3 PPC
CFM) we're getting static asserts from the alignment calculation
metafunctions. Below is an abstracted example of the problem. I'm
curious about what's going
--- David Abrahams <[EMAIL PROTECTED]> wrote:
[...]
> Something like:
>
> some_allocator<_1>
>
> or
>
> struct select_allocator
> {
> template
> struct apply
> {
> typedef some_allocator type;
> };
> };
>
> with some_allocator's interface being like
Gregory Colvin <[EMAIL PROTECTED]> writes:
> On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
>
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>>
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
>>>
>>> Or rather th
My primary question, however, is how can I share a contiguous block of
memory with a ublas vector or matrix? For example, I would like to do
something like:
double* p = new double[16];
ublas::vector v(p, 16, SHARE);
ublas::matrix v( p, 4, 4, SHARE);
where the ublas vector object, v, and matrix o
> -Original Message-
> From: David Abrahams [mailto:[EMAIL PROTECTED]
>
> Alan, did you read
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1781628
> ??
I have, but (leaving aside the argument from authority) the example is too
sketchy convincing.
I don't see how any individual er
--- David Abrahams <[EMAIL PROTECTED]> wrote:
[...]
> Just how do you propose to prevent people from writing their own
> construct/destroy functions? And if they write an allocator from
> scratch, but *don't* provide construct/destroy manually, where will
> they come from?
What I meant is that i
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
...
Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be choos
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our st
Gregory Colvin <[EMAIL PROTECTED]> writes:
>> I think part of my point was that *nobody* needs what they offer, if
>> you include construct/destroy.
>
> Or rather that some implementations have failed to use what they
> offer, and our standard unfortunately doesn't insist that they do.
It's not u
Hi Pavel!
Thank you very much for your comments. I agree with most of them. Thanks also for
the picture. Here are my notes to some of your comments.
>
> Few notes to latest source:
>
> 1. circular_buffer_adaptor.html: the link in
>
>"The circular_buffer_space_optimized is defined in
> the
At 09:09 AM 9/2/2003, Matthew Towler wrote:
>I have been attempting to build boost 1.30.2 for a number of platforms.
>
>I also wish to generate the html testsuite output for several reasons -
>My own peace of mind, because we are using a reasonably large number of
>platforms (some of which do not
At 05:17 PM 9/1/2003, Daniel Frey wrote:
>On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote:
>
>> On Thursday 28 August 2003 08:20 am, Daniel Frey wrote:
>>> utility/tie was moved to tuple, so should we remove the obsolete
>>> docs/references in utility now?
>>
>> Please do.
>
>Done. I also
On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
Conforming containers had better use them.
I'm sorry, but I think th
David Abrahams <[EMAIL PROTECTED]> writes:
> Dave Gomboc <[EMAIL PROTECTED]> writes:
>
>> [Fernando Cacciola]
>>> The most fundamental point is that being Haskell a pure functional
>>> language there is no possibly undefined behaviour to worry about,
>>> so Maybe doesn't need to address this issue
> I've done this before as well.
> But it's a very simple function.
> And I assume TestAutoSelect is a macro.
> Can I take a look at the code?
Yes, TextAutoSelect is a macro, because without using a macro, there is
no way to generate a wchar_t string literal (prefixed with L) from a
char string li
[EMAIL PROTECTED] writes:
> I've recently been discussing the guideline recently added to the exceptions
> policy page with Dave Abrahams and he has asked me to post my views here.
>
> There is a seductive form of arguement that I've seen repeatedly lead
> projects into trouble which has made me
I have been attempting to build boost 1.30.2 for a number of platforms.
I also wish to generate the html testsuite output for several reasons -
My own peace of mind, because we are using a reasonably large number of
platforms (some of which do not appear on the status tables), and so I
can see
--- David Abrahams <[EMAIL PROTECTED]> wrote:
> >>> But indeed allocate/construct/deallocate/destroy is more work than
> >> ^^^^
> >> Oyeah. These two absolutely don't belong in allocator, period. Do
> >> any implementations even use them? Allocator
--On Monday, September 01, 2003 9:52 PM -0400 Brian McNamara
<[EMAIL PROTECTED]> wrote: [snip]
As a final aside, I think much of this thread is degenerating into
Parkinson's Bicycle Shed[*], with respect to "is it a
pointer/container/X?" At this point, I think we know what set of
methods should
Douglas Gregor wrote:
> Between the two: adaptable_any is better, I think.
>
> Because I like throwing wrenches: have you considered a very different
> name such as "polymorphic" or just "poly". The idea is that we read:
>
> poly
>
> as "a type that is polymorphic over all less_than_comparable
John Maddock schrieb:
[snip]
> > If that is true: Why does the flag regbase::use_except (officially)
> > exist?
>
> It's a historical accident and should have been removed from the docs.
OK. So it seems that I should not write code which explicitely mentions
regbase::use_except?
> > Lets assume
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> Apropos of which, I now think that the Boost UserAllocator requirements
> should be the default for components that parameterize how they use
> memory, with the Standard Allocator requirements being used only for
> components that need what the
"Eric Friedman" <[EMAIL PROTECTED]> writes:
> Peter Dimov wrote:
> [snip]
>> Provide operator<. Wait six months. Collect feedback. If there is evidence
>> that operator< is evil, remove it and document why it is not supplied.
>
> OK, I'm willing to go along with this. I'll probably also include
>
Dave Gomboc <[EMAIL PROTECTED]> writes:
> [Fernando Cacciola]
>> The most fundamental point is that being Haskell a pure functional
>> language there is no possibly undefined behaviour to worry about,
>> so Maybe doesn't need to address this issue as optional<> does.
> ... and later ...
>> I accou
Eric Friedman wrote:
> Peter Dimov wrote:
> [snip]
>> Provide operator<. Wait six months. Collect feedback. If there is
>> evidence that operator< is evil, remove it and document why it is
>> not supplied.
>
> OK, I'm willing to go along with this. I'll probably also include
> operator==, with a
"Eric Friedman" <[EMAIL PROTECTED]> writes:
> Alexander Nasonov wrote:
>> Eric Friedman wrote:
>> > If I understand you correctly, earlier versions of variant did precisely
>> > what you describe. Unfortunately, the "assumption" you make is false in
>> > general. See
> http://aspn.activestate.com/
Gregory Colvin <[EMAIL PROTECTED]> writes:
> On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>>
> Conforming containers had better use them.
I'm sorry, but I think that's flat wrong. What do you suppose that
e
"E. Gladyshev" <[EMAIL PROTECTED]> writes:
>> The class getting constructed/destroyed has full control over that or
>> the language is utterly bustificated.
>
> I think construct/destroy can be implemented as non-customizable
> static functions in boost just for convinence.
Just how do you propo
I've recently been discussing the guideline recently added to the exceptions
policy page with Dave Abrahams and he has asked me to post my views here.
There is a seductive form of arguement that I've seen repeatedly lead
projects into trouble which has made me very suspicious of the form:
"provide
"Dave Gomboc" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> [Fernando Cacciola]
> > I'm saying that the choice made by variant<> in this regards is to the
> > code using get<> as hopeless as undefined behaviour. I don't think that
> > preconditions (and exceptions thereof) sh
On Mon, Sep 01, 2003 at 09:22:01PM -0600, Dave Gomboc wrote:
> [Fernando Cacciola]
> > I'm saying that the choice made by variant<> in this regards is to the
> > code using get<> as hopeless as undefined behaviour. I don't think that
> > preconditions (and exceptions thereof) should be used to arb
> Also I see the existence of boost::regbase::use_except and
> boost::regbase::failbit
> I don't see how to use them in a way to enable/disable exceptions in
> regular
> expressions, dispite probably the activation of the general
> BOOST_NO_EXCEPTIONS
> (Shame on me!).
>
> Question: It seems, that
> Thanks for your reply.
> I've created my own vcproj (VC++ 7.1 project) for building the libs that I
> need,
> and I've used the /MD flag which is the "multithread- and DLL-specific
> versions" flag (used also for my application),
> which means that everything is fine, right?
Yep.
John.
__
On Monday 01 September 2003 07:53 am, Alexander Nasonov wrote:
> I'm asking for voting for the new name of dynamic_any. Please, give you
> preference.
> Here is my discussion about the name with Kevlin Henney (>> and empty
> prefix - Kevlin, > - me)
Between the two: adaptable_any is better, I thin
[Fernando Cacciola]
> I'm saying that the choice made by variant<> in this regards is to the
> code using get<> as hopeless as undefined behaviour. I don't think that
> preconditions (and exceptions thereof) should be used to arbitrarily
> make the illusion of giving meaning to an operation that i
On Saturday 30 August 2003 08:00 am, David Abrahams wrote:
> Misha Bergal <[EMAIL PROTECTED]> writes:
> > Eric Friedman wrote:
> >> P.S. Has there been any progress in handling BoostBook documentation in
> >> CVS? Perhaps Greg or MetaComm can run nightly builds?
> >
> > We can do that. Is there any
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>
> >> variant throws throws a bad_get exception
> >> when you get a reference to a T which is not the held type. I don't see
> >> a problem why you can't do something s
On Friday 29 August 2003 10:53 pm, Eric Friedman wrote:
> P.S. Has there been any progress in handling BoostBook documentation in
> CVS? Perhaps Greg or MetaComm can run nightly builds? (This of course does
> not solve the problem of offline access though...)
There has been no progress, though it
On Tue, Sep 02, 2003 at 09:05:59AM +0800, Joel de Guzman wrote:
> My attempt to image "optional as conceptually a specialized but
> nevertheless, *IS-A* T, with the added specialization that it can
> be in a dead-uninitialized state." Is a feeble attempt to re-sell the idea
> of the concept that w
On Mon, Sep 01, 2003 at 04:05:59PM -0600, Dave Gomboc wrote:
> [Brian McNamara]
> >do_something( adapt( 3 ) );
> >do_something( adapt( nilable(3) ) );
> >do_something( adapt( foo ) ); // foo has unknown type
>
> But I'd like to write
> do_something(3);
>
Dave Gomboc <[EMAIL PROTECTED]> wrote:
> [Fernando Cacciola]
>> The most fundamental point is that being Haskell a pure functional
>> language there is no possibly undefined behaviour to worry about,
>> so Maybe doesn't need to address this issue as optional<> does.
> ... and later ...
>> I account
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>>> Direct value accesing via implicit conversion: int i = opt
>>> seems wrong because this is the operation that can lead to undefined
>>> behaviour.
>>
>> Doesn't have to be undefined behaviour.
>>
> Yes it does.
> Accesing a value that isn't there
Mat Marcus <[EMAIL PROTECTED]> wrote:
> --On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
> <[EMAIL PROTECTED]> wrote:
>
>> Joel de Guzman <[EMAIL PROTECTED]> wrote in message
>>> One can think of an optional as conceptually a specialized but
>>> nevertheless, *IS-A* T, with the add
Hello Boosters,
maybe I am blind as a bat, but I was looking for a possibility to check
a given
regular expression for its general validity.
To get rid of my problem to define "validity" I delegate its definition
to "everything
which would lead to the throw of boost::bad_expression" of all
reg_ex
Peter Dimov wrote:
[snip]
> Provide operator<. Wait six months. Collect feedback. If there is evidence
> that operator< is evil, remove it and document why it is not supplied.
OK, I'm willing to go along with this. I'll probably also include
operator==, with a similar plan for future evaluation.
--- "E. Gladyshev" <[EMAIL PROTECTED]> wrote:
>
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
> > >>> But indeed allocate/construct/deallocate/destroy is more work than
> > >> ^^^^
> > >> Oyeah. These two absolutely don't belong in allocator, perio
97 matches
Mail list logo
