On Thursday, Aug 28, 2003, at 16:26 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
How will I even know it, the documentation is completely
ignorant on the memory issues.
Perhaps because you work with the authors of the documentation to
make it sure it says what n
On Thursday, Aug 28, 2003, at 16:54 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
And I have no objection myself to adding an allocator parameter
to the shared_ptr constructor, or to making some other change that
serves the purpose. So if you need a change, why
On Thursday 28 August 2003 09:35 am, Neal D. Becker wrote:
> I have looked at std::bitset, std::vector, and boost:dyn_bitset, but
> none seems to supply a feature I need.
>
> I'd like to be able to assign to a contiguous field of bits in one
> operation. For example:
>
> bitset<12> n;
> n.subset (1
On Wednesday 27 August 2003 10:11 am, Thorsten Ottosen wrote:
> shared_ptr<> can hold incomplete types. Aparently the trick
> is to hold a pointer to a destructor function.
>
> However, from reading the code, it is quite hard to understand completely.
>
> Does anyone know some resource that describ
On Thursday 28 August 2003 06:26 pm, E. Gladyshev wrote:
> --- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> > Perhaps because you work with the authors of the documentation to
> > make it sure it says what needs saying?
>
> Are the documentation authors monitoring this mailing list?
The developers
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
>
> And I have no objection myself to adding an allocator parameter
> to the shared_ptr constructor, or to making some other change that
> serves the purpose. So if you need a change, why not just do it,
> try it out, and submit a patch?
Just wonder
"John Maddock" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> which doesn't look good at all...
>
> Oh and the problem is present in Builder 6 as well.
As suggested by Marco Oman, the problem appears to be caused by overloading
the various operators for the enum type, which happens
--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> On Thursday 28 August 2003 04:40 pm, Gregory Colvin wrote:
> > I also have no objection, and much sympathy, for having a clear
> > memory management policy for Boost libraries. But again, it is a
> > matter of people who care about and understand th
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> > How will I even know it, the documentation is completely
> > ignorant on the memory issues.
>
> Perhaps because you work with the authors of the documentation to
> make it sure it says what needs saying?
Are the documentation authors monitoring t
For those of you who are unfamiliar with pluggable factories, I suggest
reading the following C++ Report article:
http://www.adtmag.com/joop/crarticle.asp?ID=1520
To give a brief description, pluggable factories allow programmers to
create instances of a class by just referencing a class identif
"Marco Oman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Mon, 25 Aug 2003 14:31:07 +1000, Chris Trengove
> <[EMAIL PROTECTED]> wrote:
> I had once a problem like the one described and was due to the operator|()
> being overloaded for an enum type. (compiler: BCB 5.5.1)
Marco,
On Thursday 28 August 2003 04:40 pm, Gregory Colvin wrote:
> I also have no objection, and much sympathy, for having a clear
> memory management policy for Boost libraries. But again, it is a
> matter of people who care about and understand the issue doing the
> necessary work, just like everythin
Douglas Gregor wrote:
On Thursday 28 August 2003 08:20 am, Daniel Frey wrote:
>
utility/tie was moved to tuple, so should we remove the obsolete
docs/references in utility now?
Please do.
OK, will do when I find some time - if nobody objects.
Regards, Daniel
--
Daniel Frey
aixigo AG - financial t
On Thursday, Aug 28, 2003, at 10:46 America/Denver, E. Gladyshev wrote:
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
You can use all smart pointers except shared_ptr and shared_array as
they do
not allocate any memory. In particular, intrusive_ptr is a good
candidate if
memory is a concern as it ha
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, August 28, 2003 9:05 PM
Subject: Re: boost/detail/iterator.hpp update
...
> Anyone got a brilliant way to cause vc7 to print the error message?
>
#pragma message ( "som
Hello,
I've been fiddling around with boost::spirit in an
attempt to write a small and esoteric scripting language.
Here's some code snipits of what I'm trying to do.
example script (a one liner in this case):
DO_SOMETHING(param1,param2)
the grammer:
struct my_grammer : public grammar
{
Hello,
I've been fiddling around with boost::spirit in an
attempt to write a small and esoteric scripting language.
Here's some code snipits of what I'm trying to do.
example script (a one liner in this case):
DO_SOMETHING(param1,param2)
the grammer:
struct my_grammer : public grammar
{
Douglas Gregor <[EMAIL PROTECTED]> writes:
> On Thursday 28 August 2003 01:23 pm, David Abrahams wrote:
>> The other possible option would have been to simply not give the user
>> a readable error message. I'm open to opinions that I chose the
>> wrong balance.
>
> So we're breaking code in order
Douglas Gregor <[EMAIL PROTECTED]> writes:
> On Thursday 28 August 2003 01:23 pm, David Abrahams wrote:
>> The other possible option would have been to simply not give the user
>> a readable error message. I'm open to opinions that I chose the
>> wrong balance.
>
> So we're breaking code in order
Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za 'disable
language extensions' it seems that
boost::int64_t isn't available.
After a journey through the labryinthine config modules, I have got compiling
with
#define BOOST_HAS_MS_INT64 // required if language extensions disab
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
about all the repeated messages. Minor SNAFU, now cleared up.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
On Thursday 28 August 2003 01:23 pm, David Abrahams wrote:
> The other possible option would have been to simply not give the user
> a readable error message. I'm open to opinions that I chose the
> wrong balance.
So we're breaking code in order to produce a better error message? This seems
like
On Thu, 2003-08-28 at 17:46, E. Gladyshev wrote:
> --- Peter Dimov <[EMAIL PROTECTED]> wrote:
> >
> > You can use all smart pointers except shared_ptr and shared_array as they do
> > not allocate any memory. In particular, intrusive_ptr is a good candidate if
> > memory is a concern as it has smal
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
For BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION:
I've updated boost/detail/iterator so that it responds to
BOOST_TT_BROKEN_COMPILER_SPEC, and issues an error asking the user to
invoke BOOST_TT_BROKEN_COMPILER_SPEC when iterator_traits is used on
pointer types for which there's no remove_pointer spec
Bugs item #796799, was opened at 2003-08-28 12:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=796799&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Pr
Jaakko Jarvi <[EMAIL PROTECTED]> writes:
> I've noticed that call_traits doesn't support function references.
> I'm not sure whether it makes sense to store function references in
> optionals, though, but in any case.
>
> Something like this fails:
>
> typedef void (&afuncref)(int);
> typedef cal
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
>
> You can use all smart pointers except shared_ptr and shared_array as they do
> not allocate any memory. In particular, intrusive_ptr is a good candidate if
> memory is a concern as it has smaller memory footprint than shared_ptr.
Thanks, I'll conside
Vladimir,
The patch you recently checked in:
revision 1.36
date: 2003/08/28 11:48:59; author: vladimir_prus; state: Exp; lines: +53
-18
Implement depth_first_visit variant which allows to stop the search at
certain vertices.
breaks depth_first_search by aborting before it star
> >
>
> Agreed. Still, this doesn't imply you shouldn't _also_ provide
> multi-threaded libs by default. I mean, what is it to you if
> there's libboost_filesystem_mt.a, libboost_regex_mt.so, etc. for
> multi threading, while you can simply use -lboost_regex when
> linking your single threaded
I've noticed that call_traits doesn't support function references.
I'm not sure whether it makes sense to store function references in
optionals, though, but in any case.
Something like this fails:
typedef void (&afuncref)(int);
typedef call_traits::reference t;
The problem is that the call_tra
"Geurt Vos" <[EMAIL PROTECTED]> writes:
> Agreed. Still, this doesn't imply you shouldn't _also_ provide
> multi-threaded libs by default. I mean, what is it to you if
> there's libboost_filesystem_mt.a, libboost_regex_mt.so, etc. for
> multi threading, while you can simply use -lboost_regex whe
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> optional::reset ( T const& ) ;
Does it matter what happens when T is an auto_ptr?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/ma
> On Thu, 2003-08-28 at 09:00, Geurt Vos wrote:
> > >
> > > > [ this is about whether single or multi ]
> > > > [ should be the default jam option for building boost. Single ]
> > > > [ is currently the default ]
> > >
> > > (**) I think I want to hear one or two other opinions
> before we decide
Joel de Guzman <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> Take 2:
>
> typedef typename call_traits::param_type
> ctor_param;
>
> typedef typename call_traits remove_reference::type>::param_type assign_param;
>
> typedef typename call_traits::reference
> return_type;
>
>
Hi again,
Take 2:
typedef typename call_traits::param_type
ctor_param;
typedef typename call_traits::type>::param_type
assign_param;
typedef typename call_traits::reference
return_type;
optional(typename call_traits::param_type arg);
void reset(assign_param ar
There has been some discussion about a minor improvement to lexical_cast to
ensure that a loopback test like:
any_type any_value == lexical_cast(lexical_cast(any_value))
is always true
The following replacement for the original code (using digits10+1) works for
specialised radix 2 types:
if(std
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> I'm way overprotective, I guess
> (maybe it's because I'll be father for the first time
> in a couple of months :-)
Congratulations!
> The only remaining issue is the optional<> interface:
>
> Currenty, there is the following:
>
> optional::option
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
On Thursday 28 August 2003 08:20 am, Daniel Frey wrote:
> Douglas Gregor wrote:
> > I'd like to deprecate or remove two libraries:
> >
> > - min_rand has been the only entry in our list of "Obsolete Libraries"
> > for quite some time. Random is quite mature, so let's just eliminate
> > min_rand now
48 matches
Mail list logo
