I have found in the past that there is a need to
distinguish between dimension handling and unit handling.
In the case of a physical calculation, I usually ensure that
the code works with a self consistent set of units, and thus
only need dimensionality, compile time, code.
Units then
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
Cheers
Sam
- Original Message -
From: Sam Partington [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, February 27, 2003
Sam Partington wrote:
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
No, please don't drop it. I think it's a good idea, but I haven't found
the time to look at your patches closely. I will try
Aleksey Gurtovoy wrote:
If one of the developers could at least comment on this I might give it
another try. Otherwise I estimate it would take me weeks to
reverse-engineer what is happening here.
Ralf, I will definitely look into it tonight and get back to you.
OK, I've checked in a fix
Hi, Volodya,
1) It works even though I haven't got to CVS.
#ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template
struct property_traitsdefault_color_type* {
typedef default_color_type value_type;
I added it here-- typedef default_color_type reference;
typedef std::ptrdiff_t key_type;
Hi Bootsters,
I have a problem that, I think, is worth of discussion.
When developing a library I came to a to a need of a trait class, containing properties
of different containers.
There is a default behavior and a specialization for different stl containers like
vector,
basic_string and
Pavol Droba [EMAIL PROTECTED] writes:
I have tried to make forward declaration of std::vector and alike, but it does not
work all the time,
and, I think it is even forbiden by some compilers.
It's forbidden by the standard.
My question is:
Is there a correct way how to avoid these
Sam Partington [EMAIL PROTECTED] writes:
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
The code looks OK, but the submission won't be complete without
patches for the docs and tests.
--
Dave
At 11:08 AM 3/7/2003, David Abrahams wrote:
Sam Partington [EMAIL PROTECTED] writes:
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok?
Would
you like me to repost them?
Or should I just drop it?
The code looks OK, but the submission won't be complete without
Hi J-S,
Hi, Volodya,
1) It works even though I haven't got to CVS.
OK, fix comitted both to the trunk and release candidate brunch,
so it should be part of 1.30.0.
2) After it works, I set compile option back to /Gm, and it still works,
the error C1076 does not appear anymore.
That's
On Fri, Mar 07, 2003 at 10:09:40AM -0500, David Abrahams wrote:
Pavol Droba [EMAIL PROTECTED] writes:
I have tried to make forward declaration of std::vector and alike, but it does not
work all the time,
and, I think it is even forbiden by some compilers.
It's forbidden by the
Pavol Droba wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible? Or is there a way how to achieve the same efect, but
Hi,
I suggest to apply the attached patch to
libs/filesystem/build/Jamfile.v2
The patch adds boost/filesystem as project-id.
Regards,
m
Index: Jamfile.v2
===
RCS file: /cvsroot/boost/boost/libs/filesystem/build/Jamfile.v2,v
Martin Wille wrote:
Hi,
I suggest to apply the attached patch to
libs/filesystem/build/Jamfile.v2
The patch adds boost/filesystem as project-id.
Applied both to trunk and release candidate brunch.
Are you using Boost.Build V2 already?
Thanks,
Volodya
P.S. Please post further Boost.Build
On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba [EMAIL PROTECTED]
wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible?
Practically
On Tuesday, March 4, 2003, at 9:47 AM, Beman Dawes wrote:
At 02:03 AM 3/4/2003, Daryle Walker wrote:
I'm trying to use the more_io.zip stuff currently under review with a
copy of Metrowerks CodeWarrior Developement Studio (Mac OS X Edition,
v8). I haven't got anything to compile.
If there is
At 09:00 AM 2/18/2003, Markus Schöpflin wrote:
Hi there,
currently, the is_member_func_test fails for VACPP6 with the following
error messages:
/home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_functio
n_pointer.hpp,
line 37.29: 1540-1206 (S) The class template instantiation
At 03:49 PM 3/7/2003, Howard Hinnant wrote:
On Thursday, March 6, 2003, at 03:33 AM, Daryle Walker wrote:
I've attached the project I used, so maybe some Metrowerks expert can
find the obvious thing I forgot (or maybe it's actually a
misconfiguration, or [worse] a bug).
I'm a Metrowerks
On Fri, 07 Mar 2003 19:42:44 +0100, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 11:08 AM 3/7/2003, David Abrahams wrote:
Sam Partington [EMAIL PROTECTED] writes:
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches
ok?
Would
you
On Fri, Mar 07, 2003 at 04:54:14PM +, John Fletcher wrote:
Pavol Droba wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include
On Fri, Mar 07, 2003 at 08:09:35PM +0100, Gennaro Prota wrote:
On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba [EMAIL PROTECTED]
wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
Daniel Frey [EMAIL PROTECTED] writes:
Sam: I looked at the patches, especially the doc. I think you should write
some more, as you were influenced from your knowledge. I suggest you begin
with mentioning operator bool() and what's wrong with it before presenting
the solution. Think of new
--- Aleksey Gurtovoy [EMAIL PROTECTED] wrote:
OK, I've checked in a fix into the main trunk (see
boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the
problem go away, I'll integrate the new version into the release branch.
Thank you very much Aleksey! The error posted before
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
David and Aleksey, could you please review the patches and tell
me which are OK to check in? -- I am a bit worried about the
two patches in the mpl/aux_/preprocessed directory. Are these
files auto-generated? Are there master files that
The C++ Standards Committee will be meeting in Oxford, UK, April 7th
through 11th. As always, Boosters are welcome to attend as technical
experts - See http://www.boost.org/more/cpp_committee_meetings.html.
Contact me privately if you want more information.
The committee's pre-meeting papers
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
David and Aleksey, could you please review the patches and tell
me which are OK to check in? -- I am a bit worried about the
two patches in the mpl/aux_/preprocessed directory. Are these
files
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
--- David Abrahams [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
David and Aleksey, could you please review the patches and tell
me which are OK to check in? -- I am a bit worried about the
two patches in
Hereby at least a partial solution which so far works with gcc3.2 and comeau
4.3.0.1.
The complete source can be found in the sandbox :
boost-sandbox/libs/sequence_algo/test/container_traits.hpp
boost-sandbox/boost/sequence_algo/container_traits.hpp
my code does not include vector, list or map,
Ralf W. Grosse-Kunstleve wrote:
OK, I'll wait for a word from Aleksey. If he is happy I'll heck in
the eight patches, both into the trunk and the RC_1_30_0 branch.
Yep, they all look good to me.
Aleksey
___
Unsubscribe other changes:
--- David Abrahams [EMAIL PROTECTED] wrote:
It's easy enough to test it with a little program that prints the
value you have.
OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which
EDG version fixes the problem. Is this better?
Index: is_base_and_derived.hpp
Thorsten Ottosen [EMAIL PROTECTED] writes:
my code does not include vector, list or map, but it does need
iterator.
Some of the functionality of the container_traits are shown here:
template typename C
bool is_container()
{
return boost::container_traitsC::is_container();
}
...
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
--- David Abrahams [EMAIL PROTECTED] wrote:
It's easy enough to test it with a little program that prints the
value you have.
OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which
EDG version fixes the problem. Is
--- Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote:
I don't use -d0, but I don't see that **passed** message anywhere.
Something else is not right: The other fail tests are only built once, but
the as_to_python_function.cpp test is built each time I enter bjam again.
That's why you see the
--- David Abrahams [EMAIL PROTECTED] wrote:
Should be:
#if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \
!BOOST_WORKAROUND(__EDG_VERSION__, = 238)
// The EDG version number is a lower estimate.
// It is not
Beman Dawes [EMAIL PROTECTED] writes:
At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote:
... I'll check in the eight patches, both into the trunk and the
RC_1_30_0 branch.
Ralf,
Thanks for being alert to that. Please post a brief note once you have
finished all commits.
I haven't
There are going to be several talks about Boost libraries or related topics
at the ACCU conference in Oxford, UK, April 2nd through 5th:
* Design and Implementation of the Boost Graph Library by Jeremy Siek
* Metaprogramming and the Boost Metaprogramming Library by David Abrahams
* The Lambda
At 07:59 PM 3/7/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote:
... I'll check in the eight patches, both into the trunk and the
RC_1_30_0 branch.
Ralf,
Thanks for being alert to that. Please post a brief note once
I just realized that it would be impossible to use weak_ptr with any
hash. The problem is that the hash function would have to use weak_ptr's
get() method. Then if the underlying object of the weak_ptr gets destroyed,
get() will suddenly return 0 instead of the previous pointer, so the hash
--- Beman Dawes [EMAIL PROTECTED] wrote:
At 07:59 PM 3/7/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote:
... I'll check in the eight patches, both into the trunk and the
RC_1_30_0 branch.
Ralf,
What are you trying to do?
Usually weak_ptr is used as the value in a map with some other key, so
that just being in the map doesn't prevent an object from being deleted.
At 06:52 PM 3/7/2003, Joe Gottman wrote:
I just realized that it would be impossible to use weak_ptr with any
hash. The
On Friday, March 7, 2003, at 4:16 PM, Beman Dawes wrote:
At 03:49 PM 3/7/2003, Howard Hinnant wrote:
[SNIP my previous message]
I'm a Metrowerks expert, but not a boost expert. Your project is set
up to use MSL C which correctly puts ptrdiff_t into namespace std.
The above code can't find
On Fri, 07 Mar 2003 22:41:30 +0100, David Abrahams wrote:
Very nice remarks, Daniel. I have full confidence in you as the new
maintainer of the operators library.
Thanks. [Note to myself: Refrain from urging or suggesting other to urge
the maintainers :o)]
Regards, Daniel
Hi all,
Sorry for the somewhat lenghty post, but I hope it will be helpful for
someone of you.
The Boost.Spirit based C++ preprocessor iterator (the project name is
'Wave') is functionally complete now. All pp operators and pp statements
are in place, the macro expansion engine works as
Ralf W. Grosse-Kunstleve wrote:
I've checked in all my patches. I couldn't fully test the C_1_30_0
branch because Aleksey's recent fixes are not there yet.
Aleksey, please let me know when the fixes are available on the
branch.
They there now.
Aleksey
On Fri, 07 Mar 2003 11:46:24 +0100, Sam Partington wrote:
Hate to sound pushy, but I've no answer on this, were the patches ok?
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works
45 matches
Mail list logo
