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
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"
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,
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
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'
Eric Friedman wrote:
> Peter Dimov wrote:
>> When there is one and only one strict weak ordering (equality) for a
>> type, not using operator< and operator== because some users might
>> have different expectations is misguided. It is pretty clear what
>> set or find(
Gregory Colvin wrote:
[...]
Two small corrections:
> shared_ptr currently uses std::allocator to allocate counts
> regardless.
No, it uses plain new/delete by default. It is possible to get it to use
std::allocator via a #define.
[...]
> versus standard Allocator
>
>Allocator::pointer p =
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> If you want a second opinion, I'm in the "just provide operator== and
>> operator<" camp.
>
> But, IIUC, if operator< is not provided, you'd oppose a std::le
David Abrahams wrote:
> "Eric Friedman" <[EMAIL PROTECTED]> writes:
>
>> Ultimately, I do not believe any ordering scheme will provide
>> meaningful, straightforward semantics. Assuming I am correct, I
>> propose that the variant library offer your ordering scheme -- but
>> only as an explicit comp
Gregory Colvin wrote:
> * document whether and how a library allocates memory
The Throws clause is a pretty good estimate for "whether". :-)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gregory Colvin wrote:
> On Friday, Aug 29, 2003, at 18:05 America/Denver, David Abrahams
> wrote:
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>>
>>> * use the standard parameterization mechanisms (Allocator) when
>>>choosing to parameterize
>>
>> I'm not sure about this one. std::allocator a
Steve Hutton wrote:
> In article <[EMAIL PROTECTED]>, John Maddock wrote:
>>> Any thoughts on more explicitly documenting the #defines used to
>>> toggle optional features in header-only boost modules?
>>
>> What where you thinking of other than that already in
>> www.boost.org/libs/config/config.h
Daryle Walker wrote:
> On Wednesday, August 27, 2003, at 2:21 PM, Peter Dimov wrote:
>
>> I say that the primary motivation to customize memory management
>> details is that the default memory manager is slow.
>
> Just because you dislike the (so-called-by-you) primary m
E. Gladyshev wrote:
[...]
> I am actually using a separate heap in my general purpose exception
> handler.
> My exception handler is quite complex, it creates a log, compresses
> it, etc. The nice thing about it that I can still use STL containers
> while processing exceptions. All I had to do is t
Joe Gottman wrote:
>
>Has anyone considered adding a new template constructor to shared_ptr
> that takes an allocator as an extra template parameter? Something like
>
> template
> shared_ptr(Y *p, D d, Alloc alloc);
Yes, I have.
___
Unsubscribe
Vladimir Prus wrote:
> Hi,
> just now I've nearly comitted the following addition to one of BGL
> headers:
>
> + struct null_property_copier {
> +template
> +void operator()(const V1&, const V2&) const {}
> + };
> +
>
> What stopped me is that is not BGL specific at all. Is there some
> c
Daryle Walker wrote:
>
> That's an invalid argument, since the STL containers give you a default
> value for the allocator argument, which makes containers work out of
> the box, and the default is "for free."
I'm afraid it is not. The allocator parameter has a cost. It (a) prevents
some very usef
E. Gladyshev wrote:
>
> Sure he could have replaced the system allocator (I actually
> suggested it too) but why would he want to do it?
Because this saves time in the long run. Once you have a non-broken
allocator you can use third party libraries as-is, without need for
modification, and you can
Andreas Huber wrote:
>
> E.g. I hope to convince some of the embedded systems/real-time crowd
> to use the fsm lib I'm currently implementing. I would bet that even
> in 10 years most of them wouldn't even consider using it unless they
> were able to totally control how memory is allocated...
That
E. Gladyshev wrote:
> --- Peter Dimov <[EMAIL PROTECTED]> wrote:
>
>> unless there are very solid reasons for the allocator parameter. ;-)
>
> I agree, but the problme is that I don't know whether I have a solid
reason or not.
> I have to ship my class to some
Andreas Huber wrote:
> [snip]
>>> However, for a certain class of systems one almost never can avoid
>>> customization, no matter how ingenious the platform is.
>>
>> This may well be true, but I'm not convinced that platform-specific
>> customizations (an implementation detail) absolutely need to
Douglas Gregor wrote:
>
> There's no reason shared_ptr couldn't support a constructor that
> takes an allocator as an argument.
"Minimal but complete". You can already achieve this functionality with the
current interface.
___
Unsubscribe & other change
Andreas Huber wrote:
> Peter Dimov wrote:
>> The usual approach is to borrow an entry from the 2*N heap and split
>> it in two when the N heap is empty. [snip]
>
> Which brings back non-determinism, as the 2*N heap could be full also
> and thus be borrowing from 4*N al
E. Gladyshev wrote:
> I am using STL and trying to use boost in my daily
> development. What can I do to implement consistent classes in terms
> of memory management. For example, if I need to implement a class A
> that has a container and pointer to a data type. I have two options:
>
> template<
E. Gladyshev wrote:
> --- Gregory Colvin <[EMAIL PROTECTED]> wrote:
>> For shared_ptr the count is allocated by the following line in the
>> shared_count
>> constructor:
>>
>> new sp_counted_base_impl(p, d);
>>
>> So it might be possible to make the allocation customizable by
>> specializing
>>
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>>> I guess there is no equivalent to memcpy_moveable: but it looks
>>> rather dangerous, what state is the original object left in
>>> afterwards etc?
>>
>> None.
Andreas Huber wrote:
>
> I know, I just mentioned this because Peter seems to suggest that the
> need for memory management customization is rare if the compiler
> folks did their job right.
But it is. Compiler folks not doing their job is the primary motivation for
custom memory management. The C
Andreas Huber wrote:
> [snip]
>> So far my experience indicates that people only bother with
>> allocators when std::allocator is inadequate, i.e. slow.
>
> ... or non-deterministic. Using such an allocator in a hard real-time
> system is simply not an option.
> AFAIK, a deterministic allocator mus
E. Gladyshev wrote:
>
> I guess my question is that, is boost redefining the
> memory management concepts that have been established by STL?
Yes and no. The STL uses allocators for containers. Most non-containers do
not have an allocator parameter, although many standard classes do allocate
memory
John Maddock wrote:
>>> Thats my point - you may flag some types as safely moveable and then
>>> use
>>> this knowledge in algorithms. User has the responsibility to do the
>>> decision.
>>
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_
Andreas Huber wrote:
>
> If function no longer has the allocator argument, how should we then
> use function in a hard real-time environment?
In this context, an allocator parameter is only an excuse for implementors
to avoid doing the necessary work to make function<> useful out of the box.
"You
OK let's CC Samuel Krempp to make sure he's seen it.
Paul Hamilton wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> wrote:
>
>> This will work, although I had
>>
>> template inline
>> void empty_buf(BOOST_IO_STD basic_os
David Abrahams wrote:
> Jaakko Jarvi <[EMAIL PROTECTED]> writes:
>
>> 4. Non-SFINAE compilers
>>
>> Dave has an implementation of enable_if which defaults to being
>> always enabled for compilers that do not support SFINAE. We do not
>> think this is the right approach, and believe that attemts to
Paul Hamilton wrote:
> [...] I propose that we change the code:
>
> static const std::basic_string emptyStr;
>
> To:
>
> const std::basic_string emptyStr = "";
>
> Which basically does exactly the same thing.
= "" is not needed, it just forces a redundant strlen call (at least). As I
already point
David Abrahams wrote:
>
> Sure; I just don't want to have to be explicit about anything just to
> say "I'm doing native path manipulation", since I believe that's the
> 90% case. I don't want to be stopped by irrelevant portable path
> considerations nor uglify my code to avoid it.
I agree except
Paul Hamilton wrote:
> Well,
>
> I've tried to work through the solutions to:
>
> ld: common symbols not allowed with MH_DYLIB output format
>
> Which are basically "-fno-common" on the compile line of each file, but
> apart from the fact that tihs doesn't actually work in this case (we
> still
David Abrahams wrote:
>
> FWIW, Boost.Function is overkill for many simple cases. This might
> be a case where the FS library should just provide a class with a
> virtual function:
>
> struct checker
> {
> virtual ~checker() {}
> virtual bool operator()( s
Edward Diener wrote:
> Beman Dawes wrote:
>> In discussions about being able to specify a function to check the
>> validity of path element names, a simple function pointer has been
>> used:
>>
>>typedef bool (*name_check)( const std::string & name );
>>
>> Alternately, boost::function could be
Daniel Frey wrote:
> Peter Dimov wrote:
>> It is worth mentioning that this is a confirmed bug in CW
>> with -iso_templates on (unreferenced typedefs are incorrectly
>> optimized out at definition time). Masking compiler bugs in this way
>> does not help compiler writ
Daniel Frey wrote:
> Hi Dave,
>
> I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS
> HEAD. It was created in cooperation with Howard and I'm positiv that it's
> a good one-size-fits-all solution. I don't know about your shedule for
> 1.30.2, but you might want to consider mer
Beman Dawes wrote:
> At 01:40 PM 8/14/2003, Peter Dimov wrote:
> >
> >I am not sure that it should be the responsibility of the path
> class to >enforce some notion of portability. Wouldn't it be more
> appropriate to >defer the portability check, if any, t
David Abrahams wrote:
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> A path on windows that starts with '/' is a set
>>> of instructions which begins: "go to the root of the current
>>> directory path".
>>
>> Correction. It does not mean that. It means go to the root d
Glen Knowles wrote:
>> This is also a way we could solve the whole problem of absolute
>> paths. It's clear that "/foo" isn't an absolute native windows path.
>
> This is not at all clear. I have and will contain to argue that
> "/foo" is an absolute windows path, since it does not respect the
> cu
Aleksey Gurtovoy wrote:
>
> There is another variation of the idiom, sometimes called "hidden
> state", which doesn't have the shortcoming in the first place:
>
> class foo
> {
> public:
> foo();
> foo(int);
>
> int f() const;
> void g(double*);
>
>
Samuel Krempp wrote:
> format_test1 / intel-7.1
> Linker output:
>
> /opt/intel/compiler70/ia32/lib/libcprts.a(xmtx.o)(.text+0x73): In
> function `_Mtxinit':
>> undefined reference to `pthread_mutex_init'
> [...]
> /opt/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76):
> In function `.
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> Fernando Cacciola wrote:
>>> Most problems related to swap ocurr with GCC>3.3 and VC==6.0
>>> It appears that this problem ocurrs both with 1.30.0 and the current
>>> r
[EMAIL PROTECTED] wrote:
>
> Hi there. I believe that components such as shared_ptr could still
> benifit from allocators that are shared at the class level; for
> example, a singleton pool allocator could be used by all instances of
> the shared_ptr template. Loki uses exactly this, and it gains a
Russell Hind wrote:
> Peter Dimov wrote:
>>
>> To make out-of-line libraries "plug and play" we may have to
>> prefix/suffix all* inline libraries as well, making their users pay
>> for something they do not need.
>>
>> * Under the assumption that
Fernando Cacciola wrote:
> David Abrahams <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Which compilers are failing and where are the regression report
>> pages?
>>
> Sorry for the delay, I was leaving the office when you posted this
>
> Most problems related to swap ocurr wi
Alisdair Meredith wrote:
> David Abrahams wrote:
>
>> Err, I don't get it. It seems to me that you only need the hack if
>> you're going to *specialize* swap. *Using* std::swap should work
>> just fine.
>
> OK, that's because I was confused
> The following is really a minimal example, so I can b
Beman Dawes wrote:
>
> The current approach is clearly too restrictive and isn't
> satisfactory. Beyond the problems you mention, there really isn't a
> single standard for portability. Even 8.3 names aren't portable to
> systems which don't allow periods in names. A whole family of
> checkers is n
Aleksey Gurtovoy wrote:
> Consider the following snippet:
>
> void show_warning( message_dialog const&, user_message );
> void post_command( boost::function );
>
> int main()
> {
> boost::function f(
> bind( &post_command
> , ( bind( &show_w
Alisdair Meredith wrote:
>
> I am still not clear on the 'best' solution though.
> Clearly the quickest fix is to simply put the swap specialization in
> the correct namespace.
>
> However, boost code does not seem to specialize std::swap at all, but
> rather provide its own swaps in namespace boos
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 12:53 PM 8/6/2003, Russell Hind wrote:
>
> >Beman Dawes wrote:
> >>
> >> I don't think people were against the idea of solving the problem, but
> >> rather there is a need for a unified prefix/suffix header solution
such
>
> >> as John is suggesting
Fernando Cacciola wrote:
>
> BTW, I have a question:
>
> According to BCB, the primary swap is hidden when some swap is
> declared directly in std even for ADL.
> That is, not even this works:
>
> using std::swap; swap(x,y);
>
> is this conformant?
Yes, declaring things in std is undefined beh
Pavel Vozenilek wrote:
> "Jan Gaspar" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> I think, I changed mind. The flatten() method can be substituted by
>> something like this:
>>
>> void doSomething(const int* pInt, size_t numInts); // C API
>> circular_buffer intBuffer(10);
>> .
>>> "I have never quite understand why so many good, and often
>>> brilliant programmers, take it so hard when others suggest that
>>> they document what they do in easily understandable
>>> sentences. There must be something wrong in the educational
>>> systems of the countries
Alexander Terekhov wrote:
> Peter Dimov wrote:
>
>> We are discussing the
>>
>> scoped_lock l1(m);
>> l1.lock();
>>
>> case. Since l1 is required to know whether it's been locked or not
>> (it has a public locked() query) it can easily che
Daniel Spangenberg wrote:
>
> 2) For what kind of errors should be BOOST_ASSERT for?
For situations where the specification says "undefined behavior" but the
implementation can detect the problem.
Throwing an exception is sometimes an acceptable form of "undefined
behavior". Not often, of course.
Alexander Terekhov wrote:
> Peter Dimov wrote:
> [...]
>> It's not that simple. Whether something is a programming error is
>> determined by the library's specification, not vice versa. In other
>> words, under the current specification, re-locking a locked loc
Russell Hind wrote:
>
> Fair enough. My most common use is for automatically
> locking/unlocking
>
> void function(void)
> {
> scoped_lock lock(themutex);
> ... do something
> lock.unlock();
> ... do some more
> lock.lock();
> ... do something else
> }
>
> with pos
John Torjo wrote:
>> On the other hand, perhaps you have a use case that clearly
>> demonstrates
> the
>> need for BOOST_HAS_CURRENT_FUNCTION?
>
> The SMART_ASSERT library clearly needs it.
>
> The idea is: when an assertion fails, in case BOOST_CURRENT_FUNCTION
> holds a meaningful value, I want t
Edward Diener wrote:
> Once again I will make my request that Boost library developers put
> out some sort of change log explaining changes made to the library
> with each new release of Boost which is issued. While I don't expect
> detailed change enumerations, which no doubt can be retrieved thro
Daniel Frey wrote:
> On Sat, 19 Jul 2003 02:08:24 +0200, Pavel Vozenilek wrote:
>
>> "Peter Dimov" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED] ...
>> SMART_ASSERT library implements BOOST_HAS_CURRENT_FUNCTION equivalent
>> (
Peter Dimov wrote:
>
> But I don't have access to Intel C++.
I do now, fixed (hopefully), thanks for the report.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
hlh771 wrote:
> hello,everybody
> I want to test smart pointer library,but got some compile failure:
>
> vc-
> C++ ..\..\..\libs\smart_ptr\test\bin\shared_ptr_alloc_test.test\msvc\d
> ebug\runtime-link-dynamic\shared_ptr_alloc_test.obj
> shared_ptr_alloc_test.cpp
> M:\develop\boost_1_30_0\boost/det
Daniel Frey wrote:
> On Tue, 15 Jul 2003 22:22:03 +0200, Peter Dimov wrote:
>
>>> +#include
>>> +#if defined(BOOST_INTEL)
>>> +#include
>>> +#endif
>>
>> Dependencies. I hate dependencies.
>
> Do you have a better idea?
Several, lik
Daniel Frey wrote:
>
> To explain the bug a bit: When you create a small test case, you'll
> probably get the error from the compiler you are looking for. If you
> put
> the checked_delete in it's own header, it still works as long as you
> include the header with
>
> #include "my_header.h"
>
> but
Howard Hinnant wrote:
> On Sunday, July 13, 2003, at 08:49 AM, Peter Dimov wrote:
>
>> Maybe the problems are caused by overloading void_. I haven't looked
>> at MPL
>> recently, but as a general observation I have identified at least
>> three uses
>>
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>>>
IMO we should just stop using 'void_' for internal purposes and
give it up to users :).
>>>
>>> I am still unsure about 'void_' being better
Stefan Slapeta wrote:
> ... and the reason is that this Boost workaround
>
> # if BOOST_WORKAROUND(BOOST_MSVC, <= 1200 && __SGI_STL_PORT)
>
> does never apply as config.hpp is not included and therefore
> BOOST_MSVC IS NOT SET!!!
> You have to manually include config.hpp before intrusive_ptr to m
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams wrote:
>>> Jaakko Jarvi <[EMAIL PROTECTED]> writes:
>>>
>>>> Where we've used enable_if, it has been very common that the
>>>> c
David Abrahams wrote:
> Jaakko Jarvi <[EMAIL PROTECTED]> writes:
>
>> Where we've used enable_if, it has been very common that the
>> condition is not just a single traits lookup, but rather a logical
>> expression, e.g.:
>>
>> template
>> typename enable_if::value &&
>> is_vector::value,...>::typ
David Abrahams wrote:
>
> IIUC, there are no absolutes here (i.e. no law says "there is an
> implicit guarantee"). Legally, it's just a question of what looks
> like an attractive/vulnerable target. IIUC, the deal is that without
> an explicit disclaimer, lawyers feel they have more leverage in
Alexander Terekhov wrote:
> Glen Knowles wrote:
> [...]
>> The Common Public License already has a section in the wiki and fails
>> the boost requirements as shown.
>>
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/Common_Public_License
>
> Yeah. That "review process"
David Abrahams wrote:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> * Why is the new license better?
>
> I'll get the lawyers to comment on this in more detail, but here are
> some answers as I understand them:
>
>Big picture: it has been v
Hugo Duncan wrote:
> Hi,
>
> I am trying to use bind with __fastcall member funtion.
>
> Just including bind.hpp with BOOST_BIND_ENABLE_FASTCALL defined is
> giving compile
> errors on bcc 5.5 and cbuilder 6 with patch 4.
>
> Am I missing something, or is this broken?
>
> Hugo
>
>
> #define BOOST_B
Ed Brey wrote:
> Peter Dimov wrote:
>>
>> I'd like also to point out that it seems to me that the old "in all
>> copies" form is better than the new one; the legal system is
>> sufficiently flexible
>> to reliably recognize a "copy" (i.e.
Beman Dawes wrote:
>
> Let's see what the lawyers say before worrying too much about what
> may be a non-issue.
I'd like to add some of my concerns to the list.
First of all let me say that I fully realize that we just got a ton of free
legal advice and that I do appreciate the efforts of everyon
Daniel Frey wrote:
>> Inspired by an article at the CUJ from Andrei Alexandrescu, I was
>> finally able to come up with a compose_f_gxy_hxy-adapter.
You've considered
bind(f, bind(g, _1, _2), bind(h, _1, _2))
right? ;-)
___
Unsubscribe & other changes:
Aleksey Gurtovoy wrote:
> Peter Dimov wrote:
>>
>> Also, please note that I don't mind the _developer summary_ being
>> "aggressive" in its pass/fail reports. There are no "expected
>> failures" there as far as I'm concerned. Ever
Aleksey Gurtovoy wrote:
> Peter Dimov wrote:
>> Aleksey Gurtovoy wrote:
>>>
>>> Well, check out the latest developer report -
>>>
>> http://boost.sourceforge.net/regression-logs/developer_summary
>> _page.html!
>&
Aleksey Gurtovoy wrote:
> Peter Dimov wrote:
>>
>> Note also that Beman's intel-win32 toolset passed shared_ptr_test but
>> your intel-win32 toolset did not, and I can't distinguish the two in
>> expected_results.xml.
>
> We just need to agree on the con
Aleksey Gurtovoy wrote:
>
> Well, check out the latest developer report -
> http://boost.sourceforge.net/regression-logs/developer_summary_page.html!
Intel-7.1 is misconfigured. ADL is disabled but
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is not set. That is why
intrusive_ptr_test and shared_ptr_test fa
Aleksey Gurtovoy wrote:
> Peter Dimov wrote:
>
>> The summaries are nice, but the red "broken" thing on the user page
>> may be too intimidating,
>
> When will show the actual status, it shouldn't be (it doesn't yet,
> since
> some cooperation
Aleksey Gurtovoy wrote:
> ... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
> are available from here:
>
> * user summary page -
> http://boost.sourceforge.net/regression-logs/user_summary_page.html
> * developer summary page -
> http://boost.sourceforge.net/regression-logs/dev
Bruno MartÃnez wrote:
> Hi,
> I was wondering if it was possible to have two weak pointers that
> together own an object. That is, if one of the two is destroyed the
> other fails to construct a shared_ptr, but as long as both exist the
> object is not destroyed, even if no other weak/shared ptr ex
Gennadiy Rozental wrote:
> Hi,
>
> I am having problems with subject test with Metrowerks compiler. I
> was able to minimize the issue to the following snippet:
> #include
> #include
>
> template
> inline void
> print( std::ostream& ostr, T const& t, long ) { ostr << t; }
>
> template
> inline vo
John Maddock wrote:
> Subject says it all, as it stands boost/any.hpp isn't even open
> source, please reuse an existing boost licence if possible, thanks,
The license is at the end.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinf
Hamish Mackenzie wrote:
>
> 3) Why dom::basic_document::clone? Why not have the copy constructor
> and assignment operator should do a deep copy of the document? This
> is consistent with other containers. If you want to stick with clone
> return
> an auto_ptr and and derive basic_document from b
Alex Chovanec wrote:
>
> I suppose for starters, you could create a generic binary function for
> operator< and other operators, maybe something like this:
>
> template
> struct ptr_less
> {
> bool operator()(const T * lhs, const T * rhs)
> {
> return (*lh
Stefan Seefeld wrote:
> Peter Dimov wrote:
>>
>> I think that there is considerable interest in a boost::xml library.
>> But...
>>
>> Document *document = Document::parse_file(argv[1]);
>>
>> ... I don't believe that a raw pointer based int
Stefan Seefeld wrote:
>
> Is there any interest in this library evolving
> into a boost::xml library ? If so, what needs to change,
> what needs to be added / removed ?
I think that there is considerable interest in a boost::xml library. But...
Document *document = Document::parse_file(argv[1
Raoul Gough wrote:
> Noticed from a recent posting to comp.lang.c++.moderated from KIM
> Seungbeom ([EMAIL PROTECTED]):
>
> libs/smart_ptr/index.htm claims that "scoped_ptr can ease the
> management of memory dynamically allocated in other ways."
> (i.e. other than with a new expression). This isn'
David Abrahams wrote:
>
> # if defined(_MSC_VER) && (_MSC_VER <= 1300) // added check for <=
> VC 7 (Peter Dimov)
[...]
> # ifndef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
> #define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
> # endif
> # define BOOST_NO
Chuck Messenger wrote:
> What is the status of sp_collector.cpp? It's distributed as part of
> Boost right now. Is it intended to remain part of the shared_ptr
> library? It sounds like it should suit my purposes quite well, after
> all...
sp_collector.cpp has a "gift" status. ;-) Meaning that
Chuck Messenger wrote:
> Schoenborn, Oliver wrote:
>
> Imagine that I'm supplying a network simulation library. I have:
>
> #include
> #include
> #include
> #include
>
> using namespace std;
> using namespace boost;
>
> struct Node;
>
> struct NodeImpl :
Chuck Messenger wrote:
>
> boost/libs/smart_ptr/src/sp_collector.cpp:
>
> There is no sample program to compile/run, so I have to guess somewhat
> at how to use this one.
There is libs/smart_ptr/test/collector_test.cpp. You need to #define
BOOST_SP_ENABLE_DEBUG_HOOKS.
The basic idea of the algori
Larry Evans wrote:
> Chuck Messenger wrote:
>> The basic idea is to intercept all memory allocations -- p = new X;
>> --
>> saving the info with "map[p] = sizeof(X);". To find the
>> interconnections between objects, you do this:
>>
>> for (map_type::iterator it = map.begin(); it != map.end()
Beman Dawes wrote:
> Providing both the fine-grained and the coarse-grained headers lets the
> users decide which they prefer.
Sounds reasonable. CVS updated.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1 - 100 of 446 matches
Mail list logo
