Terje Slettebø wrote:
By the way, just for fun. Adding the following output operator for
arrays,
to the header I gave in the previous posting:
---
|O|X|O|
---
|X|X|O|
---
|O|O|X|
---
Shall we play a game? :)
Sure thing :-)
I guess you maybe got the War Games
Hi,
I tried to use the regression tests with the interval library; and it
worked: I just ran run_tests.sh on a linux computer with gcc 3.2.2 and
intel cc 7.0 and looked at the results. So, if nobody objects or does it
before me, I will modify status/Jamfile so that it automatically handles
the
On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:
At 05:06 PM 2/4/2003, Matthias Troyer wrote:
I have run the regression tests on a Cray SV1 system using the Cray
C++
3.6 compiler and posted the results on
http://www.comp-phys.org/boost/cs-sn9626.html
Why don't you consider
Le mer 05/02/2003 à 10:27, Matthias Troyer a écrit :
It seems that on all Crays the macros CRAY and cray are defined. If one
wants to be machine specific, we got this information recently:
On Wednesday, January 22, 2003, at 05:58 PM, Dan Gohman wrote:
On the Cray T3D, Cray T3E, and Cray
Andreas Huber wrote:
Hi there
Hi Andreas,
I tried to use mpl::is_sequence on an incomplete type and ran into
errors suggesting that the argument must not be incomplete (I'm using
MSVC 7.0). I assume this cannot be fixed, right?
It might be possible to fix it, but it will require some
Joel de Guzman wrote:
Yaiks! I hope it gets fixed soon. Spirit has been committed to
the boost CVS now and I just switched to MPL so Spirit relies
on MPL now.
If you look at the errors more closely, you'll see that it's not MPL,
but 'is_convertible' that is broken, for Borland 5.5.1; yes,
Aleksey Gurtovoy wrote:
Joel de Guzman wrote:
Yaiks! I hope it gets fixed soon. Spirit has been committed to
the boost CVS now and I just switched to MPL so Spirit relies
on MPL now.
If you look at the errors more closely, you'll see that it's not MPL,
but 'is_convertible' that is broken,
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
- operator*
- operator-
- static_cast
- dynamic_cast
- incomplete type support
- auto_ptr construction/assignment
:-)
From: Paul A. Bristow [EMAIL PROTECTED]
This looks really neat - and potentially very useful.
Thanks. :)
Sadly, array is one of the most interesting cases - so I'm sure I won't be
the
only one 'watching this space'.
I've looked more into it, and it seems this is a problem not just for MSVC,
Aleksey,
It might be possible to fix it, but it will require some work. Let
me know if it's important for you, and I'll move it up in my TODO list.
Well, it is not that important since mpl::is_sequence is only used to
provide some syntactic sugar. I could just as well tell my users that they
If you look at the errors more closely, you'll see that it's not MPL,
but 'is_convertible' that is broken, for Borland 5.5.1; yes, hopefully
things will be restored soon (John?).
Yep, done, apologies for the interruption, normal service will be restored
soon :-)
John Maddock
I noticed that is_class actually detects classes only for the Metrowerks
and the VC++, other compilers use a fall-back implementation which works
by detecting everything but classes and thus everything which remains has
to be a class. This is IMHO broken as i.e. member functions are detected
Most my porting to borland recently has involved a couple of new bugs
introduced in BCB6. Rather than testing compiler and version
everywhere, should I instead create some BOOST_SOME_DEFECT macros in the
borland config file and test for those instead? If so, any suggestions
for the macro
From: Terje Slettebø [EMAIL PROTECTED]
const int array[3];
std::cout array;
MSVC 7 - C
Intel C++ 7 - C
g++ 3.2 - C
const char array[3];
std::cout array;
MSVC 7- A (S or C)
Intel C++ 7 - C
g++ 3.2 - C
std::cout Test;
MSVC 7 - A (S or C)
Intel 7 - C
On Tue, 4 Feb 2003 07:25:52 -0500, Dave Abrahams
[EMAIL PROTECTED] wrote:
In that case it would seem likely that it could be fixed by reverting to
C-style cast, no?
I've seen in the CVS that the casts are to support enums. But the
documentation for integral_c says
An Integral Constant is a
Gennaro Prota [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Tue, 4 Feb 2003 13:03:05 -0300, Fernando Cacciola
[EMAIL PROTECTED] wrote:
Dave Abrahams wrote:
On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
Joel de Guzman [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003 12:02:17 -, John Maddock
[EMAIL PROTECTED] wrote:
basically they put C lib
functions in namespace std, and C++ library code in namespace stlport, and
then use:
namespace std{
using namespace stlport;
}
to import the STLport code into std. Unfortunately it doesn't work
Gennaro Prota [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Tue, 4 Feb 2003 07:25:52 -0500, Dave Abrahams
[EMAIL PROTECTED] wrote:
In that case it would seem likely that it could be fixed by reverting to
C-style cast, no?
I've seen in the CVS that the
Jeremy, I see this in docs:
boost::graph_traitsG::directed_category
The choices are directed_tag and undirected_tag.
However, the following code:
typedef typename boost::graph_traitsMutableGraph::directed_category dir;
dir()[10];
Produces this message:
Fernando Cacciola [EMAIL PROTECTED] wrote in message
b1r24q$c16$[EMAIL PROTECTED]">news:b1r24q$c16$[EMAIL PROTECTED]...
typedef integral_cT, (integral_cT, N::value) + 1 next;
typedef integral_cT, (integral_cT, N::value) - 1 prior;
[snip]
I agree, at least in theory; though I
Peter Dimov wrote:
Paul Mensonides wrote:
[deep breath]
I think that he thought that you might have thought that the
cv-qualified specializations would match
pointers-to-cv-qualified-member-functions rather than just
cv-qualified-pointers-to-members.
Yes, exactly. Apologies for
Obviously you missed the delights of reading Karl May's Winnetou when you
were a kid :o).
:-) Yes, I've missed this. I started to read in English not too long
time ago.
[snip]
Looks great. However, all these behaviors can be, and most were, trivially
implemented as policies of SmartPtr,
Another problem is that the type long long exists but is not supported
by the standard library (e.g. the operator (std::ostream, long long)
is not defined). Since long and long long are both 64 bit there is
actually no need to ever use long long. I'll have to check why long
long is used
Greeting,
I have cleaned up the documentation and added a dummy example of a
displaced operator new and operator delete (displaced.cpp). It takes for
granted that each library will deallocate its previously allocated block.
In this case it is not really a problem since I am using STL
Pavel Vasiliev wrote:
Conclusion: IMO, policy-based implementations like Loki::SmartPtr
and fixed ones like boost::shared_ptrT or my refc_ptrT serve
different needs. Do I say something new? Hardly.
Hoare/Knuth:
Premature optimization is the root of all evil
Me:
Premature flexibility is
On Wednesday, February 05, 2003 8:37 AM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
That given, a member-function-pointer should match is_class, shouldn't
it? In fact all pointers should IMHO match is_class with this
implementation. Maybe it's just me but the boost source is feeling
Here's what I've made so far the a Cray platform and compiler config
file. As Matthias pointed out, a reasonable stdint.h is available, so
having this configuration makes the __crayx1 customizations to
boost/cstdint.hpp unnecessary.
Also as Matthias mentioned earlier, the Cray C++ library is
On Wednesday, February 05, 2003 9:32 AM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
Pavel Vasiliev wrote:
Conclusion: IMO, policy-based implementations like Loki::SmartPtr
and fixed ones like boost::shared_ptrT or my refc_ptrT serve
different needs. Do I say something new? Hardly.
Daniel Frey wrote:
Peter Dimov wrote:
Yes, exactly. Apologies for the confusion. It is a common mistake to
provide only R T::* and expect that to match all pointers to
members. To get back to your earlier post,
int (X::*pf) () const;
is not the same as
typedef int (*F) () const;
Should
On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
The lack of support of standard library functions associated with
long long is a problem on other platforms and other functions (eg:
std::abs). This has been a headache for me using the int64_t in
date-time.
So I presume that the
On Wednesday, February 5, 2003, at 11:42 AM, Samuel Krempp wrote:
Le mer 05/02/2003 à 10:27, Matthias Troyer a écrit :
It seems that on all Crays the macros CRAY and cray are defined. If
one
wants to be machine specific, we got this information recently:
On Wednesday, January 22, 2003, at
On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
I am looking into it but already have a conjecture. When using signed
64 bit integers the Cray compiler (with optimization turned on) uses
the floating point units to actually perform the operations
On Wednesday 05 February 2003 10:27, Matthias Troyer wrote:
On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:
After we get the regrssion tests to work, there will be a special
challenge for ublas or MTL-3: Calling the BLAS routine where
appropriate will be essential in getting
Curiously the one failure for date-time
was in handling of big time durations. The failure is
probably an overflow problem, which can happen if you try
to use a plain 32-bit integer to get nano-second resolutions
and large time durations. Nano-second resolution is the default
Terje Slettebø wrote:
It should handle maps and pairs
reasonably well. I think that I have the same complaints about this as
io_manip
The saving of information to the stream means that you can affect all
future output...
For instance, if you have a type
mapcustom_object,
Dave Abrahams wrote:
On Wednesday, February 05, 2003 8:37 AM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
That given, a member-function-pointer should match is_class, shouldn't
it? In fact all pointers should IMHO match is_class with this
implementation. Maybe it's just me but the
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Implementing of refc_ptr as a set of policies is also possible, but
currently that seems to be overkill, both in unnecessary
complexity and performance losses. Though this my opinion may
Bjorn Karlsson and I are wondering if Boost should require copyrights on
Jamfiles.
Obviously if a Jamfile author wants to copyright a Jamfile he or she
creates, that fine.
But what about Jamfiles where the author didn't add a copyright? Do the
lawyers care, or are these files to minor to
On Wed, 5 Feb 2003 10:30:01 -0300, Fernando Cacciola
[EMAIL PROTECTED] wrote:
Gennaro Prota [EMAIL PROTECTED] wrote in message
Enumerations are not integral types. Also, the presence of next and
prior exposes the use with enumerators to undefined behavior. Do we
really want that?
Good
On Wednesday, February 05, 2003 10:55 AM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
Dave Abrahams wrote:
On Wednesday, February 05, 2003 9:32 AM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
Premature flexibility is the root of all evil
Stone me, Andrei :o)
I
On Wednesday, February 05, 2003 11:14 AM [GMT+1=CET],
David B. Held [EMAIL PROTECTED] wrote:
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Implementing of refc_ptr as a set of policies is also possible, but
currently that seems to be
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote:
Hi,
I tried to use the regression tests with the interval library; and it
worked: I just ran run_tests.sh on a linux computer with gcc 3.2.2 and
intel cc 7.0 and looked at the results. So, if nobody objects or does it
before me, I will modify
David B. Held wrote:
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Implementing of refc_ptr as a set of policies is also possible, but
currently that seems to be overkill, both in unnecessary
complexity and performance losses. Though
On Wednesday, February 05, 2003 11:18 AM [GMT+1=CET],
Beman Dawes [EMAIL PROTECTED] wrote:
Bjorn Karlsson and I are wondering if Boost should require copyrights on
Jamfiles.
Obviously if a Jamfile author wants to copyright a Jamfile he or she
creates, that fine.
But what about Jamfiles
All,
(Note: I'm not critiquing the design choices, just trying to
understand the choices and the behavior of the implementation)
I read in the docs that simultaneous reads are ok, but simultaneous
read/write or write/write are not. Ok, seems like a valid set up.
When I looked at the
Dave Abrahams [EMAIL PROTECTED] wrote in message
04dc01c2cd3a$219279c0$7901a8c0@penguin">news:04dc01c2cd3a$219279c0$7901a8c0@penguin...
[...]
Lots of ways. For example, the smart pointer objects could be
bigger than neccessary.
;) I'm working on it!
[...]
Type generators are overkill,
Beman Dawes wrote:
Bjorn Karlsson and I are wondering if Boost should require copyrights on
Jamfiles.
Jamfiles are part of the build system; they won't become part of
a an executable. So everything is fine when a vendor ships a
binary or a DLL.
However, when Boost is incorporated to some other
Hi,
First I would like to apologize if what I am going to propose have already been
suggested, discussed and rejected. If that is the case, please ignore this
message.
I would like to suggest a new interface (and implementation) for boost:thread. A
problem with the current version
At 03:56 AM 2/5/2003, Guillaume Melquiond wrote:
However, something bothers me. In the big array with all the tests and
compilers (cs-something.html), library names are wrong. For example, all
the tests for ublas and interval are mixed under the same library called
numeric. Is it possible for the
On Wednesday 05 February 2003 09:11 am, Beman Dawes wrote:
Last point, is there something wrong with the linux computer used for the
regression tests on http://boost.sourceforge.net/regression-logs/ ? With
gcc 3.2, it fails 179 tests. When I gave it a try for the interval
library, I got a
On Wednesday, February 05, 2003 1:00 PM [GMT+1=CET],
David B. Held [EMAIL PROTECTED] wrote:
[...]
Type generators are overkill, since unlike with iterator adaptors
there's no need to preserve type identity. Normal inheritance will
work just fine.
That's a good point. Do you think
Gennaro Prota wrote:
On Wed, 5 Feb 2003 10:30:01 -0300, Fernando Cacciola
[EMAIL PROTECTED] wrote:
Gennaro Prota [EMAIL PROTECTED] wrote in message
Enumerations are not integral types. Also, the presence of next and
prior exposes the use with enumerators to undefined behavior. Do we
On Wednesday, February 5, 2003, at 04:24 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
I am looking into it but already have a conjecture. When using signed
64 bit integers the Cray compiler (with optimization turned
An absolutely invaluable tool.
Perhaps worth documenting for MSVC 7.0 (and probably 6.5?)
1 Need to have language extensions enabled. (for WINNT?)
2 Need to have /EHa rather than /EHs for async exceptions. (for WINNT?)
3 std for loop scope is OK.
4 Warnings level 4 ok, (except get two
On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
On Wednesday, February 5, 2003, at 04:24 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
I am looking into it but
On Wednesday, February 5, 2003, at 08:22 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET],
Matthias Troyer [EMAIL PROTECTED] wrote:
Actually there were two problems. One was the one you mentioned above.
The other was that we needed either a masking to 32 bits or
I'm reposting this, because I think, that this bug should be fixed, but
there wasn't any response to the first mail. I would try to fix it
myself, but the errors are so weird, that I'm not able to grasp, how to
do it :-)
Regards Hartmut
-Original Message-
From: [EMAIL PROTECTED]
First I would like to apologize if what I am going to propose have
already been suggested, discussed and rejected. If that is the case,
please ignore this message.
I would like to suggest a new interface (and implementation) for
boost:thread. A problem with the current version
Trey Jackson wrote:
All,
(Note: I'm not critiquing the design choices, just trying to
understand the choices and the behavior of the implementation)
I read in the docs that simultaneous reads are ok, but simultaneous
read/write or write/write are not. Ok, seems like a valid set up.
When
Philippe A. Bouchard wrote:
Greeting,
I have cleaned up the documentation and added a dummy example of a
displaced operator new and operator delete (displaced.cpp). It takes
for granted that each library will deallocate its previously
allocated block.
In this case it is not really a
On Wed, 05 Feb 2003 18:08:21 +0100, Dave Abrahams wrote:
On Wednesday, February 05, 2003 10:55 AM [GMT+1=CET], Daniel Frey
[EMAIL PROTECTED] wrote:
Dave Abrahams wrote:
On Wednesday, February 05, 2003 9:32 AM [GMT+1=CET], Daniel Frey
[EMAIL PROTECTED] wrote:
Premature flexibility
Hi Ove,
f. It shall be possible to send extra information, as an optional
extra argument
to the boost::thread ctor, to the created thread.
boost::thread::self shall offer a method for retrieving this extra
information. It is not required that this information be passed in
a
On Wednesday, February 05, 2003 3:04 PM [GMT+1=CET],
William E. Kempf [EMAIL PROTECTED] wrote:
What I would like to see is a new boost::thread implementation
which meets the following requirements.
a. There shall be two interfaces to a thread. One for creation of a
thread, from
David Bradley wrote:
Q. I am not convinced. Default parameters can be used where
appropriate to hide the complexity. Again, why not policies?
A. Template parameters affect the type. See the answer to the
first question above.
I don't get this argument. Isn't that exactly what
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Obviously you missed the delights of reading Karl May's Winnetou when
you
were a kid :o).
:-) Yes, I've missed this. I started to read in English not too long
time ago.
Same here, I didn't speak
[2003-02-05] Ronald Garcia wrote:
Howdy,
I would like to request the addition of the -ansi flag to the
intel configuration file for boost build. I have received some bug
reports that don't show up unless that flag is enabled. Since I
understand little of how boost build works, what follows is
On Wednesday 05 February 2003 09:11 am, Beman Dawes wrote:
Sound suspicious. Alkis?
When I run the tests and pass with all the toolsets at once the gcc toolsets
uses gcc2.95.3 configuration.
Part of the script that creates gcc2953-tools.jam:
cat
Hi Dan,
Thanks for your input regarding the Cray X1. My efforts to port my
codes to Cray vector machines are aimed at using an X1 in the future,
and I use our SV1 machines at this time mainly to sort out problems,
to vectorize my codes and for first tests.
On Wednesday, February 5, 2003, at
On Wednesday, February 5, 2003, at 04:52 PM, Toon Knapen wrote:
On Wednesday 05 February 2003 10:27, Matthias Troyer wrote:
After we get the regrssion tests to work, there will be a special
challenge for ublas or MTL-3: Calling the BLAS routine where
appropriate will be essential in getting any
At 01:16 PM 2/5/2003, Martin Wille wrote:
Beman Dawes wrote:
Bjorn Karlsson and I are wondering if Boost should require copyrights
on
Jamfiles.
Jamfiles are part of the build system; they won't become part of
a an executable. So everything is fine when a vendor ships a
binary or a DLL.
Peter Dimov wrote:
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
- operator*
- operator-
Not these two--at least not for any reasons that I see.
- static_cast
-
Peter Dimov wrote:
(Hi, Peter. I'm merging two different posts on this subject and replying to
both simultaneously.)
Yes, exactly. Apologies for the confusion. It is a common mistake to
provide only R T::* and expect that to match all pointers to
members. To get back to your earlier post,
In [EMAIL PROTECTED]">news:[EMAIL PROTECTED],
Gennaro Prota [EMAIL PROTECTED] typed:
needed is a strong word :-) If you qualify the name:
typedef integral_cT, (integral_cT, N::value) + 1 next;
typedef integral_cT, (integral_cT, N::value) - 1 prior;
then Borland digests it.
Nice
double d;
threaddouble t = spawn(foo)(a,b,c);
// do something else
d = thread.return_value();
A solution like this has been proposed before, but I don't like it. This
creates multiple thread types, instead of a single thread type. I think
this will only make the
[2003-02-05] Ronald Garcia wrote:
On Wed, 5 Feb 2003, Rene Rivera wrote:
[2003-02-05] Ronald Garcia wrote:
I would like to request the addition of the -ansi flag to the
[ ... ]
Some questions...
Are the errors in Boost code, or your code?
err...both (boost code that happens to be my
From: Jason House [EMAIL PROTECTED]
Terje Slettebø wrote:
It should handle maps and pairs
reasonably well. I think that I have the same complaints about this
as
io_manip
The saving of information to the stream means that you can affect all
future output...
For instance,
On Wednesday, February 05, 2003 5:58 PM [GMT+1=CET],
Ronald Garcia [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003, Rene Rivera wrote:
[2003-02-05] Ronald Garcia wrote:
I would like to request the addition of the -ansi flag to the
[ ... ]
Some questions...
Are the errors in Boost
Peter Dimov wrote:
How do you write a factory function that doesn't pass a smart pointer across
library boundaries?
I guess it depends on what you're defining as library. I'm thinking of
things like DLL's and Unix style shared libraries as opposed to staticly
linked libraries. In these
Peter Dimov wrote:
The overhead is usually acceptable, even with a plain pthread_mutex.
Agreed. With that in mind, why wasn't the shared_ptr *also* protected
by a mutex?
Thereby making the simultaneous read/write safe (safe in that no
memory would be leaked b/c the pointers written/read).
It just occurred to me that this trick only works when the underlying
pointer type is a real pointer. In other words, if smart_ptr is to be able
to provide array access, while wrapping arbitrary pointer-like types, an
operator[] is still required.
On Wed, 5 Feb 2003, Dave Abrahams wrote:
On Wednesday, February 05, 2003 5:58 PM [GMT+1=CET],
Ronald Garcia [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003, Rene Rivera wrote:
[2003-02-05] Ronald Garcia wrote:
I would like to request the addition of the -ansi flag to the
[ ...
- Original Message -
From: Dave Abrahams [EMAIL PROTECTED]
It just occurred to me that this trick only works when the underlying
pointer type is a real pointer. In other words, if smart_ptr is to be able
to provide array access, while wrapping arbitrary pointer-like types, an
David B. Held wrote:
Pavel Vasiliev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
In my implementation of refc_ptr operator= performs
incrementing/decrementing within a single guarded section (since
the only global instance of interl. op. mutex
Wolfgang Bangerth wrote:
[...]
async_resultdouble res;
thread t(bind(res.call(), a, b, c));
// do something else
d = res.value(); // Explicitly waits for the thread to return a value?
This does the same, indeed. Starting a thread this way is just a little
more complex (and -- in my
On Wednesday, February 05, 2003 7:26 PM [GMT+1=CET],
Ronald Garcia [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003, Dave Abrahams wrote:
On Wednesday, February 05, 2003 5:58 PM [GMT+1=CET],
Ronald Garcia [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003, Rene Rivera wrote:
[2003-02-05]
On Wednesday, February 05, 2003 6:37 PM [GMT+1=CET],
David Bradley [EMAIL PROTECTED] wrote:
From what I can
tell, since smart_ptr has no traits, there's no way for library
^
You must mean shared_ptr
implementors to deal with this scenario, other than to abandon smart
At 11:31 AM 1/28/2003, Beman Dawes wrote:
The tentative release schedule for 1.30.0 looks like:
January 31 - Finish commits of major new components.
February 14 - Branch for release.
By end of February - Final release.
This schedule is still looking good.
I'm taking a mini-vacation
Dave Abrahams wrote:
Actually, shared_ptr magically deals with this problem by instantiating the
deleter at the point where it takes ownership of its resource. As long as
that's on the same side of the DLL boundary where the resource was
allocated, you're golden.
That's something I missed
On Wednesday, February 05, 2003 3:53 PM [GMT+1=CET],
Daniel Frey [EMAIL PROTECTED] wrote:
Which compiler? How were you using intrusive counting?
I used some benchmark code which compared several smart-pointers (my own
and the boost version). I had a simple class
#define LOAD int dummy[2];
Paul A. Bristow [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
An absolutely invaluable tool.
Perhaps worth documenting for MSVC 7.0 (and probably 6.5?)
1 Need to have language extensions enabled. (for WINNT?)
Do I use any nonstandard language extensions?
On Wednesday, February 05, 2003 9:18 PM [GMT+1=CET],
David Bradley [EMAIL PROTECTED] wrote:
Dave Abrahams wrote:
Actually, shared_ptr magically deals with this problem by instantiating
the deleter at the point where it takes ownership of its resource. As
long as that's on the same side
91 matches
Mail list logo
