Dear Boosters,
(questions regarding contributing to boost at the end of this mail)
I have made a:
templatetypename T struct sequence_arrayT;
which has an interface that is almost compatible with
std::vectorstd::vectorT ;
but faster.
Rationale:
I often worked with vectors of sequences, two
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
// ***
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
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
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
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,
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 optional 3rd arg
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
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
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
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
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 problem
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, BCC55sp2 chokes on
Forward Inline
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
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
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 outside
Forward Quoted
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
Forward Inline
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
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
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*. In
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
- 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
#endif
22 matches
Mail list logo