The compiler complains about an ambiguity between operator int() and
operator bool() when we try to use bool conversion. Removing the operator
int() declaration solved the ambiguity.
The good news is that work-around is no longer necessary starting with Sun
CC 5.4 (0x540).
On another hand, we sti
Hi
On Fri, May 23, 2003 at 09:15:58AM +0400, Vladimir Prus wrote:
[snip]
> I'll keep this in mind. In fact, I plan to convert all the documentation
> into BoostBook is the library is accepted. The Doxygen is very nice --- in
> fact, it helps very much to keep everything documented. But I found
- Original Message -
From: "Rob Stewart" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2003 8:15 PM
Subject: Re: [boost] Re: Formal Review: Command Line & Config library
> From: "James Curran" <[EMAIL PROTECTED]>
> > Chuck Messenger wrote:
> > >> * add_options() sh
I've read many comments and so there're some of my thoughts.
uBLAS is a very nice library but I'm not sure that conceptually geometrical
primitives would fit in its context very well. Looking forwardly, there
would be not only hom. vectors and matrices but other geom. primitives as
well, e.g., seg
Hi Pavel,
> Hello John,
>
> > > 1. #include may be replaced with #include
> > >
> > > However Dimkunware C++ library for MSVC 6 does put functions
> > into
> > > std:: namespace, so
> >
> > Unfortunately, it's not true (at least not for my MSVC6 ;-))
> >
> My typo. It should be DOESN'T.
>
> #in
On Wednesday 21 May 2003 14:39, Jeff Garland wrote:
> Did you look at the attached test program which had this traits adapter?
nope. I must have missed that although I check all attachments (I think)
> static time_duration_type make_time_duration(time_rep start, time_rep end)
> {
> a
> I understand why you might need additional parsers. The important point
> about them is that it's easy to add them. Since the parsing part is
> hidden behing the "parse*" functions, to add a new parser one would need
to
> only to add "parse_xml_config_file" function. Probably some of such
> funct
- Original Message -
From: "Pavel Vozenilek" <[EMAIL PROTECTED]>
To: "John Torjo" <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2003 11:25 PM
Subject: one small assert fix
> boost/smart_assert.hpp can have code:
>
> #ifndef ...
> #define ...
>
> #if _MSC_VER >= 1020
> #pragma once
> #en
> John Torjo wrote:
> >> 3. In addition to __FUNCTION_ GCC has __PRETTY_FUNCTION__ and C99
> >> __func__ (I think). Other platforms may have their own (like
> >> __function__).
> >
> > Thanks!
> > Basically, I would be interested in all of these unportable macros.
> > The more the merrier, since
Hi Tanton,
Tanton Gibbs wrote:
> I have to say that I'm a little torn over this library. I really like its
> simplicity and usefulness; however, I wish it were more of a facade on a
> more complex library. For example, I would like to be able to have
> multiple config file parsers for winini,
>
> However, given the generally accepted meaning of an assertion, I
> have no problem with using BOOST_ASSERT for debug only tests and
> BOOST_VERIFY for debug and release tests. (Another name might be
> BOOST_CHECK.) I don't do Windows programming -- or at least I
> haven't done any in a few ye
Hi Pavol,
Pavol Droba wrote:
> I have tried to use program_options library. I have compiled the library,
> ran the examples and then incorporated the library into one of my
> projects.
Thanks for putting time into this!
> First and in my opinion the most important one is the matter of
> documen
current_function.hpp doesn't include Intel C++ where __FUNCTION__ can be
used. It is more-less equivalent of GCC __FUNCTION__ (not the pretty one).
No other similar macro works. It is not listed in official documentation but
(likely) provided as GCC compatibility feature.
Tested configurations:
-
I have to say that I'm a little torn over this library. I really like its
simplicity and usefulness; however, I wish it were more of a facade on a
more complex library. For example, I would like to be able to have multiple
config file parsers for winini, tag=value,xml, or other config file types.
Forgive me if I am jumping in inappropriately but if this is of
interest... I recently started using shared_ptr to solve a problem in my
app, and found that I needed to set BOOST_DISABLE_THREADS
since I don't need the thread safety built in to shared_ptr. The app
handles that itself.
But this sled
Rob Stewart wrote:
From: "James Curran" <[EMAIL PROTECTED]>
Chuck Messenger wrote:
* add_options() should use references rather than pointers
"Pointer for return value" is C semantics. In C++,
pointers denote optional values. Non-const references are for return
values.
I disagree *strongly*.
Vladimir Prus wrote:
Chuck Messenger wrote:
* Library-managed default values
I think it good idea. Need to flesh some details a bit.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Managed_Default_Values_-_Program_Options_Suggestion
Replace default_value() with optional
Joseph Seigh wrote:
>
> Alexander Terekhov wrote:
> >
> > Joseph Seigh wrote:
> > > Well, Detlefs calls it lock-free reference counting. But Boost
> > > would probably call what they're doing with thread-safe reference
> > > counting lock-free also, and they are not the same.
> >
> > They don't
Rob Stewart wrote:
> Disagree strongly all you want, but I only use pointers to
> indicate optional arguments and to pass references (general
> meaning of the word) to objects that are expected to outlive the
> object to which they are given (usually in the ctor). In the
> former case, the argumen
From: "John Torjo" <[EMAIL PROTECTED]>
>
> > > If VERIFY is used in MFC to mean an assert even in release mode then
> that
> > is
> > > probably the best name.
> > In MFC it doesn't have that meaning though. It means that the expression
> > passed to VERIFY will get evaluated in the release build
Joseph Seigh wrote:
>
> Alexander Terekhov wrote:
> >
> > Joseph Seigh wrote:
> > > Well, Detlefs calls it lock-free reference counting. But Boost
> > > would probably call what they're doing with thread-safe reference
> > > counting lock-free also, and they are not the same.
> >
> > They don't
Alkis Evlogimenos, who has been doing a great job running the Linux
regression tests, is moving to Urbana-Champaign, Illinois to pursue a Ph.D.
in CS at the University of Illinois.
Thanks again to Alkis!
He won't be available to continue running tests this summer. That means we
need a voluntee
I applied the patch. So for gcc < 2.96, lambda now includes deque, and
works as a compensation for this extra dependency.
Jaakko
On Thu, 22 May 2003, Daniel Frey wrote:
> Jaakko Jarvi wrote:
> > I can't now even get the deque error you mention, can you send me
> > the error listing (maybe outs
All,
I believe there is a bug in the BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
implementation of recursive_try_mutex::do_trylock. The bug is the result
of an invalid assertion, that pthread_mutex_trylock should always return
0. The attached test case demonstrates the error. If the following patch
is
From: "James Curran" <[EMAIL PROTECTED]>
> Chuck Messenger wrote:
> >> * add_options() should use references rather than pointers
>
> > "Pointer for return value" is C semantics. In C++,
> > pointers denote optional values. Non-const references are for return
> > values.
>
> I disagree *str
Original Message
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 22 May 2003 19:37:13 +0200
From: Alexander Terekhov <[EMAIL PROTECTED]>
Newsgroups: comp.programming.threads
Subject: shared_ptr/weak_ptr and thread-safety
References: ... <[EMAIL PROTECTED]>
Joseph Seigh wrote:
>
> A
Jaakko Jarvi wrote:
I can't now even get the deque error you mention, can you send me
the error listing (maybe outside of boost list). Maybe there is a better
way to fix it instead of including deque.
The error was exactly what I quoted in the first posting of this thread.
The gcc uses a non-conf
"Chris Trengove" <[EMAIL PROTECTED]> writes:
>> I don't know that any BCCs can do it. AFAIK they're all buggy.
>> Someone was working on a port; I think he got pretty far.
>
> I think I am the "someone", and I am fairly sure that no version of BCC will
> compile BP.
>
>> Nope, when I try it, BCC5
> I don't know how good a fix that really is, and for all I
> know it may break other compilers (including VC7.0).
> But it ought at least let you get on with what you're doing,
> until a new release (compiler or library) that fixes
> the problem for real.
Just FYI on the "strict typenames" issue
Hi,
I have tried to use program_options library. I have compiled the library, ran the
examples and then
incorporated the library into one of my projects.
All worked quite fine.
I have few remarks.
First and in my opinion the most important one is the matter of documentation.
I find it very ha
At 07:31 AM 5/22/2003, John Maddock wrote:
>> - Detects some regex problems that previously only Metrowerks was
>>detecting.
>
>Working on it.
Looks like you're making some progress - today's regex tests for Comeau are
looking better:-)
>> * Shows what looks like a Boost config prob
In my opinion this proposal should be split into two parts:
1) an efficient container for short fixed size vectors and matrices and
operations on them, similar to TinyVector in Blitz++. This might
be part of ublas.
2) a geometry library built on this TinyVector
Matthias
__
Dear Boosters,
After a cvs update I am having probles compiling cregex.cpp on an Intel
Linux platform with the KC compiler. The problem seems to be an
ambiguity in a call to destroy(..). While this is probably a bug in the
KCC compiler, I would appreciate a workaround (e.g. changing the name
o
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn
> Sent: Thursday, May 22, 2003 6:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [boost] proposal for efficient geom. vector class
> As for the point/vector/matrix from a non-graphics point-of-view
Hi,
The problems with 2.95 were in bind overloads and deducing function
references, if I remember correctly. However, the bind
overloading was changed at some point for other reasons, and that can have
fixed the trouble.
I can't now even get the deque error you mention, can you send me
the error
> It should save some work to define these objects in terms of geometric
> algebra.
While I fully agree with this, you might find you'll have a hard time
convincing other people of this. Many people are so locked into the
traditional concepts of linear algebra that a geometric library without
matr
Vladimir Prus wrote:
> Holger Grund wrote:
>> It expands to 13103077 (RTM).
>
> Thanks! BTW, what's "RTM"?
Release To Manufacturing.
-cd
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Chuck Messenger wrote:
>> * add_options() should use references rather than pointers
> "Pointer for return value" is C semantics. In C++,
> pointers denote optional values. Non-const references are for return
> values.
I disagree *strongly*. In C and C++, the address-of syntax clearly
ind
Chuck Messenger wrote:
> >>* Library-managed default values
> >
> > I think it good idea. Need to flesh some details a bit.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Mana
>ged_Default_Values_-_Program_Options_Suggestion
>
> Replace default_value() with option
It should save some work to define these objects in terms of geometric
algebra.
How about Jaap Suter's Geometric Algebra library?
http://jaapsuter.com/
-Joshua
-Original Message-
[...]
i suppose it would be neat to have boostified vectors
as we have boostified quaternions, octonions, e
Some brief thouhgts from the various comments. (Sorry if I dont credit you,
I am a bit bust at the moment).
There are many libraries available that are aimed at solving these problems
(uBlais, Blits++, MTL and others). The problem is that these are not
standardized, are generally non-portable (
I should also mention that I have a patch which solves the problem by
replacing the forward declaration of deque with a real include in
boost/lambda/detail/operator_return_type_traits.hpp. Really
strait-forward. But am interested in the general support of lambda for
this compiler, as the proble
Hi,
I was finally able to upgrade our company's boost installation from
1.25.1 to 1.30.0 last week :)) I happily tried to use it, but I ran into
a small problem: The compiler we are using is still the gcc 2.95.2 with
no chance for an upgrade in the foreseeable future. When I included
boost/lam
Hi Justinas,
do you mean something like this? Please regard code below.
Using the second parameter of the template arguments to define the size of a
vector, so that you can call specialized functions for the right dimension?
Greets,
Patrick
// ***
templat
Dear Boosters,
(questions regarding contributing to boost at the end of this mail)
I have made a:
template struct sequence_array;
which has an interface that is almost compatible with
std::vector >;
but faster.
Rationale:
I often worked with vectors of sequences, two examples:
1. typedef s
45 matches
Mail list logo