[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
Ross Smith <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Neal D. Becker" <[EMAIL PROTECTED]> writes: >>> >>> You mean I can't just run bjam with no options and get the libs >>> built with thread support? I need to add a command-line option? >> The libraries that require thread support will be built with thread >> support. The others will not, unless multi has been placed >> in their default-build settings; single is the global >> default. > > Which leads to three questions: > > (1) How do we do this? Do what? Get all multithreaded libraries automatically with zero user intervention on the command-line? You convince the Boost developers who told me single-threading should be the default when I started Boost.Build that they were wrong, and I change the default. > (2) Why isn't it documented? Are users supposed to know about this bit > of voodoo by clairvoyance, or what? Yes. > (3) How many other undocumented gotchas like this are lurking in there? 63 and a half. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: what happened to allocators in boost?
Peter Dimov wrote: [snip] >> I see your point but what is the alternative? Forcing people to >> replace global new/delete? > > In a word, yes. Although replacing global new/delete is forced by the > system allocator being not up to the task and not by us. > > I understand that for some applications region-based memory > management can > be a big performance win. I also understand that some (uncommon in my > experience) cases can't be supported by a global allocator (when two > independent regions are active at once, in a single thread.) But I'm > not > sure that Allocators (as spelled in the standard) are the answer, and > I'm entertaining the thought that in the long term this kind of > customization harms the C++ community. Maybe not one's particular > corner of the community, but the community as a whole. I agree but we're stuck with a hen/egg problem, as you have already pointed out. Today, quite a few system allocators are not up to the task, so people absolutely need customization. For cross-platform stuff this is true until the very last platform has come around, which might be never :(. Moreover, for some platforms compiler implementers can always argue that they cannot satisfy most of the crowd anyway, so customization and the sub-standard allocators will remain. 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... Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
David Abrahams wrote: "Neal D. Becker" <[EMAIL PROTECTED]> writes: You mean I can't just run bjam with no options and get the libs built with thread support? I need to add a command-line option? The libraries that require thread support will be built with thread support. The others will not, unless multi has been placed in their default-build settings; single is the global default. Which leads to three questions: (1) How do we do this? (2) Why isn't it documented? Are users supposed to know about this bit of voodoo by clairvoyance, or what? (3) How many other undocumented gotchas like this are lurking in there? -- Ross Smith .. Pharos Systems, Auckland, New Zealand "I virtually never go out of the house with less computing power on my person than the entire North American continent circa 1973." -- Charlie Stross ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
> From: David Abrahams [mailto:[EMAIL PROTECTED] > Subject: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas? > > > "Patrick Kowalzick" <[EMAIL PROTECTED]> writes: > > > Hi Matthew, > > > > I like these statistics. Nice graphs. > > > > Did you test the block_prod compared to normal prod as well ? This > > would be interessting compared to ATLAS as well. An early version of block prod is there in my pdf, it is the one in the centre at the 1000 point, on the right. The BTL/opencascade link shows Atlas, but the current version of atlas performs quite a bit better. The uBLAS performance may be a little dated as the guys have done lots of work. Especially w.r.t. SSE/SSE2/vectorisation benefits. Atlas wrapping has been improved AFAIK, as ATLAS has since the results on the BTL page. Also the Intel Math Kernel Library results I had were called from a uBLAS matrix, calling DGEMM directly, so it still benefits, I feel, from nicety of uBLAS. > It's very hard to read, IMO. It's not clear what the lines > are referring to and some of them look too similar to be > distinguished. For sure. That is nearly the point for some though. GCC and VC benefit a little from the assign syntax, not not a huge amount as the lines are close together and are hard to distinguish. It is interesting to note the great differences you can get with Intel C++ depending on your optimization settings, which I find a battle to get right. But yeah, the graph aint pretty and it isn't too meaningful without more context. Matt. > >> > Now, is there any performance result data about uBlas ? > >> > > >> This is one of the better sources of results... > >> > >> http://www.opencascade.org/upload/87/index.html > >> > >> There is a small chart I did a while back at > >> http://groups.yahoo.com/group/Boost-Users/files/ > >> Called uBLA performance. > >> ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- Peter Dimov <[EMAIL PROTECTED]> wrote: > 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 someone else. She might have a solid reason, I > don't know. > > If I supply an allocator parameter, then I am covered and I can sleep > well. :) > > Well... if you ask me, it is better to not offer the functionality until > someone explicitly asks for it and gives a reasonable scenario as an > example. Features are easy to add, hard to remove, and there is always the > possibility that you "pre-included" the wrong feature. Ok, I'll let my users know who is to blame. :) I agree, if I am to use boost, providing an allocator parameter doesn't make much sense. shared_ptr news the ref counter and in general, boost doesn't allow a full memory management customization anyway. I agree that the STL allocators may not be the answer but then, what is. Counting on the standard allocator is certainly not an answer either. I am afraid that some of the boost libraries (as they are now) won't work for a big group of real time and embedded developers, where customization is the key. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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 someone else. She might have a solid reason, I don't know. > If I supply an allocator parameter, then I am covered and I can sleep well. :) Well... if you ask me, it is better to not offer the functionality until someone explicitly asks for it and gives a reasonable scenario as an example. Features are easy to add, hard to remove, and there is always the possibility that you "pre-included" the wrong feature. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
Beman Dawes <[EMAIL PROTECTED]> writes: > At 10:08 PM 8/25/2003, David Abrahams wrote: > >David Abrahams <[EMAIL PROTECTED]> writes: > > > >> > What about: > >> > > >> > assert( p.branch_path().empty() ); > >> > > >> > Isn't that closer to what you are trying to express? > >> > >> I guess so. I didn't see branch_path(). > > > >BTW, it would feel much more natural to me if it were > > > > path root() const; > > path branch() const; > > path leaf() const; > > > >but because of the portable-ization of non-portable windows path > >constructs, I think something this simple is impossible. > > It isn't just Windows - multi-rooted file systems with named roots are > a feature of many operating systems. Not to mention URI/URL's. It isn't multi-rooted systems which cause the problem, though. It's the need to represent paths that are only rooted under some notion of "the current root", e.g. the windows path "/foo". -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Spirit question...
Jan,
That was my problem - thank you.
Chris.
- Original Message -
From: "Jan Langer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 26, 2003 11:29 AM
Subject: [boost] Re: Spirit question...
> Chris Cooney wrote:
> > I've been utilizing some of the other boost projects for awhile now but
> > am new to the spirit framework and may ask some dumb questions...so,
> > sorry in advance.
>
> i tried it today for the first time. and i think its really nice.
>
> > I'm wondering why the var_delm rule won't work when parsed:
> >
> > rule<> var_delm = +anychar_p;
>
> maybe
> rule <> var_delm = +(anychar_p - ch_p (')'));
> will work
>
> > rule<> var_type = str_p("some_literal") | str_p("some_literal_2") |
> > var_delm ;
> > rule<> script_func1 = str_p("FUNC_NAME") >> ch_p('(') >> var_type
> > >>ch_p(')');
>
> the var_type production also reads the closing parenthesis.
>
> > to clarify,
> >
> > FUNC_NAME(some_literal) -> parsing succeeds
> > FUNC_NAME(some_literal_2) -> parsing succeeds
> > FUNC_NAME(kjfd*&) -> parsing fails (note: "kjfd*&" is just a
> > example...actually nothing I pass will work)
>
> --
> jan langer ... [EMAIL PROTECTED]
> "pi ist genau drei"
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
[...]
> template struct X
> {
> typedef typename A::value_type T;
>
> static T * create(A & a)
> {
> T * p = a.allocate(1);
>
> try
> {
> new(p) T;
> }
> catch(...)
> {
> a.deallocate(p, 1);
> throw;
> }
>
> return p;
> }
>
> static void destroy(A & a, T * p)
> {
> p->~T();
> a.deallocate(p, 1);
> }
> };
>
> The above doesn't respect A::pointer etc.
>
> Now you can _almost_ do the straightforward thing:
>
> template< class T, class A = std::allocator >
> struct Y
> {
>shared_ptr _data;
>std::list _list;
>Y(): _data( X::create(), X::destroy ) {...}
> };
I would change the definition of create/destroy in X<>:
static T * create(A & a = A() );
static void destroy(T * p, A & a= A());
Anyway it seems like a good solution, but it won't work pretty
for the reasons that you described later in your post.
shared_ptr should keep its own copy of A just like std::list does.
Then it'll be consistent with what people are used to in STL.
>
> except that X::create and ::destroy take a reference to an allocator.
> This should remind you that you forgot the allocator argument in the
> constructor:
Good point, I just ommitted it for simplicity sake.
>
> Y(A const & a = A()): ...
>
> Now _list will make itself a copy of that 'a'. This immediately hints at a
> potential problem:
>
> template< class T, class A = std::allocator > struct Z
> {
>std::list _list;
>std::list _list2;
> };
>
> where _list and _list2 will make their own copies and can't be made to share
> a single allocator instance. But let's ignore that (presumably the author of
> a stateful A will use a shared_ptr<> underneath so that copies
> use the same heap) and get back to our list+shared_ptr.
Yes, I am aware of this problem, shared_ptr or a static heap member will work.
>From my experience, it is exactly the case. Typically you don't want to
keep per-instance data in A.
> Now who should own the allocator that is used to construct or later destroy
> *_data? Should we use _list.get_allocator() for that? We can't since a copy
> of Y will copy _list but share _data, and the original may get destroyed
> along with the allocator. So we'll need to do something along the lines of:
>
> Y(A const & a = A()): _list(a), _data()
> {
> A a2(a); // original is const
> T * p = X::create(a2); // evaluation order
> _data.reset( p, bind(X::destroy, a2, _1) );
> }
>
> Not very pretty, but that's what you need to pay for being
> std::allocator-based; its interface is tailored for containers. For such a
Exactly, like I said before, shared_prt should keep its own copy of A.
> case I'd definitely consider going back to
>
> template< typename T > struct A
> {
>shared_ptr _data;
>std::list _list;
> };
>
> 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 someone else. She might have a solid reason, I don't know.
If I supply an allocator parameter, then I am covered and I can sleep well. :)
>
> Or you can write your own alloc_ptr, of course, if you want to go the
> allocator route; it is quite a different beast compared to shared_ptr as it
> doesn't support polymorphism, for example, so it deserves its own name.
Perhaps, alloc_ptr should be included in boost. It'll give us a standard way to
integrate boost
and STL.
>
> But your code still looks somewhat artificial to me; why would you want to
> deep copy _list but shallow copy _data? It doesn't make much sense.
It is just an example. I agree, it does look artificial, but you can imaging
something along the
lines:
template< typename T, template A >
{
shared_ptr< T, A > _data;
shared_ptr< std::list< T,A >, A > > > _list;
};
It uses template template parameters and both _data and _list are shared.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
Thomas Witt <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> Thomas Witt <[EMAIL PROTECTED]> writes: >>> >>>- - A full boost-conformant implementation is available in the sandbox >> Or in Boost CVS, I hope... since if it's already in use it may >> already be there. > > I assume that in general the new component would have a new place and > add some tweaks. Furthermore I would not want to make a general > exception to the review-first-boost-CVS-then idea. That being said, > something that is in boost CVS already doesn't need to be moved to > sandbox for review purposes. > >> >>>- - The submitter posts an fasttrack review announcement to the list >>>(should this go to boost-announce as well?). Review period should last >>>for 5 days. No two fasttrack review should run in parallel. Fasttrack >>>review may run during full reviews, though generally this should be avoided. >> No review manager intervention at all? > > Yep this is going to be lightweight process. If it doesnt play out we > can change it accordingly. > >> Hmm, I'd rather you make the >> announcement. > > I can check the preconditions and do the scheduling as well as the > announcement, if you want me to. That'd be great; I just think it shouldn't be up to one person alone (usually the author of a component) to initiate a review. Someone needs to be there to say "this isn't worthy/ready/small enough/whatever" just in case. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 10:08 PM 8/25/2003, David Abrahams wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> > What about: >> > >> > assert( p.branch_path().empty() ); >> > >> > Isn't that closer to what you are trying to express? >> >> I guess so. I didn't see branch_path(). > >BTW, it would feel much more natural to me if it were > > path root() const; > path branch() const; > path leaf() const; > >but because of the portable-ization of non-portable windows path >constructs, I think something this simple is impossible. It isn't just Windows - multi-rooted file systems with named roots are a feature of many operating systems. Not to mention URI/URL's. Early versions of the interface had only the three decomposition functions you mention above. IIRC, they even had those names. Almost immediately users came up with cases where they needed to distinguish between the root name and the root directory. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 09:48 PM 8/25/2003, David Abrahams wrote:
>"Rainer Deyke" <[EMAIL PROTECTED]> writes:
>
>> It is my understanding that paths are implemented as
>> std::vector or something similar, where the individual
>> strings can contain slashes if the underlying filesystem allows it.
>> It would be a shame if filesystem::path was unable to represent
>> legal native paths just because they contain characters which have
>> special meaning in the portal path grammar.
>>
then 'p.leaf()' may contain any character that is supported by the
native file system, which may include slashes. When 'p.leaf()' is
then converted back into a 'filesystem::path', the resulting path
will have different sematics than intended. This strikes me as very
dangerous.
>>>
>>> Oh, is that what happens now? Yipes!
>>
>> Yipes indeed.
>
>I am finding Rainer's arguments quite convincing. Beman, what do you
>think about this?
When this was discussed in the past, one suggested solution was to
represent slashes via an escape mechanism. That's the approach RFC2396
takes. The other suggestion was to treat slashes like '\0'; just ban them.
But that discussion never went anywhere since it isn't an issue for the
current POSIX/Windows implementation.
I'm certainly in agreement that before adding implementations for any file
or operating systems that would have that problem we have to deal with it
safely.
>Also, his last point makes me think that perhaps path ought to have
>push_back so we can *add* an element with a slash in it.
>
>If a path really *is* a container of strings, I have no problem with
>having functions which build paths by parsing strings in various ways,
>but it seems like those functions don't belong in the path
>constructor. What about, simply:
>
> struct path : std::vector
> {
> // forwarding constructors
> };
I really don't view a path as a container of strings, at least not to the
point of being willing to publicly derive from std::vector. A
container of strings seems a really useful conceptual model for how a path
might store data internally. That conceptual model has helped answer
various questions that were really troublesome before the model. But the
intent was always to hand-tailor the actual interface to make it easy to
write the kinds of code envisioned as the typical uses of the library.
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... > But even for a POD type such as this, copying would lead to > errors if the char * data were dynamically allocated since a double delete > would probably be done. > Containers aware of memcpy_moveable can detect this flag and avoid double delete problems. Other code would use constructors/destructors as usual. Intention is to give user chance to flag performance sensitive types. Commonly used containers/algorithms (typically vector) would be able to take advantage of this. This soulution would work with current compilers and could be useful for performance optimisation phase of a project. Code using memcpy_moveable<> can play some tricks to help troubleshooting (like filling old storage with debug bit pattern). memcpy_moveable<> cannot be deduced by compiler automatically, IMO - that's real disadvantage. Also memcpy_moveable<> is intended for situations where large arrays of objects are moved, like vector<> reallocations. It is something different and likely orthogonal to Mojo or standard move proposals. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: what happened to allocators in boost?
Peter Dimov wrote: > 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 already. You can of course guarantee >> an upper limit for an allocation, as some heap must have a slot >> available. > > Actually it's possible that all free memory already went to the N/2 > heap but this case is (even more) unsolvable with predetermined heap > sizes, too. :-) > >> However, for some systems this upper limit is already too slow, so >> someone inevitably has to configure heap sizes *before* startup. > > I agree, but I still don't see why a quality system allocator on such > a system should not give you the ability to do so. True, but this is just not yet standard. Not that I have an awful lot of experience with such systems but the (very popular) platform of the one project I was involved with was far away from providing such a quality allocator. Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: what happened to allocators in boost?
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 be >> supported by a portable mechanism affecting the interface. > > I see your point but what is the alternative? Forcing people to > replace global new/delete? In a word, yes. Although replacing global new/delete is forced by the system allocator being not up to the task and not by us. I understand that for some applications region-based memory management can be a big performance win. I also understand that some (uncommon in my experience) cases can't be supported by a global allocator (when two independent regions are active at once, in a single thread.) But I'm not sure that Allocators (as spelled in the standard) are the answer, and I'm entertaining the thought that in the long term this kind of customization harms the C++ community. Maybe not one's particular corner of the community, but the community as a whole. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Spirit question...
Chris Cooney wrote:
I've been utilizing some of the other boost projects for awhile now but
am new to the spirit framework and may ask some dumb questions...so,
sorry in advance.
i tried it today for the first time. and i think its really nice.
I'm wondering why the var_delm rule won't work when parsed:
rule<> var_delm = +anychar_p;
maybe
rule <> var_delm = +(anychar_p - ch_p (')'));
will work
rule<> var_type = str_p("some_literal") | str_p("some_literal_2") |
var_delm ;
rule<> script_func1 = str_p("FUNC_NAME") >> ch_p('(') >> var_type
>>ch_p(')');
the var_type production also reads the closing parenthesis.
to clarify,
FUNC_NAME(some_literal) -> parsing succeeds
FUNC_NAME(some_literal_2) -> parsing succeeds
FUNC_NAME(kjfd*&) -> parsing fails (note: "kjfd*&" is just a
example...actually nothing I pass will work)
--
jan langer ... [EMAIL PROTECTED]
"pi ist genau drei"
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: memcpy_copyable<> and memcpy_moveable<> type traits
"John Maddock" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > He needs to take a look at the has_trivial_* traits: > > has_trivial_assign is roughly equivalent to memcpy_copyable > > I guess there is no equivalent to memcpy_moveable: but it looks rather > dangerous, > It looks dangerous but the memcpy_moveable is intended for containers designed to deal with this danger. (The problem can be a bit alleviated (in debug mode) by overwriting old storage by 0xCC bit pattern, making invalid use easier to spot.) Combination of is_POD and has_trivial_* covers many cases for memcpy_moveable but not all of them, IMO. Also the has_trivial_* are not yet supported by compilers. My intention was to give user chance to flag moveable types manually. Those causing performance bottleneck could be examined and flagged without need to change container/algorithm/architecture. Performance optimization is often targeted after system gets built and being able to improve it without major design changes looks useful. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Spirit question...
Hello,
I've been utilizing some of the other boost
projects for awhile now but
am new to the spirit framework and may ask some
dumb questions...so,
sorry in advance.
I'm wondering why the var_delm rule won't work
when parsed:
rule<> var_delm = +anychar_p;
rule<> var_type = str_p("some_literal") |
str_p("some_literal_2") | var_delm ;
rule<> script_func1 = str_p("FUNC_NAME")
>> ch_p('(') >> var_type
>>ch_p(')');
to clarify,
FUNC_NAME(some_literal) -> parsing
succeeds
FUNC_NAME(some_literal_2) -> parsing
succeeds
FUNC_NAME(kjfd*&) -> parsing
fails (note: "kjfd*&" is just a example...actually nothing I pass will
work)
Again, sorry for the ignorance and the toy example
and thanks for the effort.
Chris.
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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 changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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 already. You can of course guarantee > an upper limit for an allocation, as some heap must have a slot > available. Actually it's possible that all free memory already went to the N/2 heap but this case is (even more) unsolvable with predetermined heap sizes, too. :-) > However, for some systems this upper limit is already too slow, so > someone inevitably has to configure heap sizes *before* startup. I agree, but I still don't see why a quality system allocator on such a system should not give you the ability to do so. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: what happened to allocators in boost?
[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 be > supported by a portable mechanism affecting the interface. I see your point but what is the alternative? Forcing people to replace global new/delete? Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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< typename T >
> struct A
> {
>shared_ptr _data;
>std::list _list;
> };
>
> template< typename T, template A = std::allocator >
> struct A
> {
>shared_ptr _data;
>std::list _list;
>A : _data( new T() ) {...}
> };
>
> The problem with the first defenition is that I am limiting the
> built-in STL functionality in terms of memory management.
>
> The problem with the second definition is that if I expose the
> allocator template parameter, the user of my class will expect that
> all memory allocations of type T are going to be using her allocator
> but boost::shared_ptr doesn't support it.
It does... to an extent. You can't customize the count allocations, but they
aren't T allocations. For the T allocation you'll need something along the
lines of:
template struct X
{
typedef typename A::value_type T;
static T * create(A & a)
{
T * p = a.allocate(1);
try
{
new(p) T;
}
catch(...)
{
a.deallocate(p, 1);
throw;
}
return p;
}
static void destroy(A & a, T * p)
{
p->~T();
a.deallocate(p, 1);
}
};
The above doesn't respect A::pointer etc.
Now you can _almost_ do the straightforward thing:
template< class T, class A = std::allocator >
struct Y
{
shared_ptr _data;
std::list _list;
Y(): _data( X::create(), X::destroy ) {...}
};
except that X::create and ::destroy take a reference to an allocator.
This should remind you that you forgot the allocator argument in the
constructor:
Y(A const & a = A()): ...
Now _list will make itself a copy of that 'a'. This immediately hints at a
potential problem:
template< class T, class A = std::allocator > struct Z
{
std::list _list;
std::list _list2;
};
where _list and _list2 will make their own copies and can't be made to share
a single allocator instance. But let's ignore that (presumably the author of
a stateful A will use a shared_ptr<> underneath so that copies
use the same heap) and get back to our list+shared_ptr.
Now who should own the allocator that is used to construct or later destroy
*_data? Should we use _list.get_allocator() for that? We can't since a copy
of Y will copy _list but share _data, and the original may get destroyed
along with the allocator. So we'll need to do something along the lines of:
Y(A const & a = A()): _list(a), _data()
{
A a2(a); // original is const
T * p = X::create(a2); // evaluation order
_data.reset( p, bind(X::destroy, a2, _1) );
}
Not very pretty, but that's what you need to pay for being
std::allocator-based; its interface is tailored for containers. For such a
case I'd definitely consider going back to
template< typename T > struct A
{
shared_ptr _data;
std::list _list;
};
unless there are very solid reasons for the allocator parameter. ;-)
Or you can write your own alloc_ptr, of course, if you want to go the
allocator route; it is quite a different beast compared to shared_ptr as it
doesn't support polymorphism, for example, so it deserves its own name.
But your code still looks somewhat artificial to me; why would you want to
deep copy _list but shallow copy _data? It doesn't make much sense.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
"Peter Dimov" <[EMAIL PROTECTED]> writes: > 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 >>> sp_counted_base_impl. >> >> I think it would be great. >> >> However there is another problem. >> You have to new your object. >> shared_ptr s( new MyClass ); > > You can allocate your object however you want: > > shared_ptr s(MyClass::allocate(), MyClass::deallocate); > > and of course there is also the textbook way of defining a suitable > MyClass::operator new. That leaves out the question of count allocation. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: what happened to allocators in boost?
Peter Dimov wrote: > 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 must inevitably have a separate heap >> for each possible object size. The difficult part is reserving enough >> slots in each heap at startup, before deterministic reaction is >> necessary. I don't see how a system could do this automatically when >> memory is scarce. > > 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 already. You can of course guarantee an upper limit for an allocation, as some heap must have a slot available. However, for some systems this upper limit is already too slow, so someone inevitably has to configure heap sizes *before* startup. > Even if the system allocator does not work for you, why would you > want to only replace function<>'s allocator but leave all other > allocations non-deterministic? Because function objects absolutely have to be allocated during the phase when a system has to react deterministically. Other objects might be allocated before this phase. I guess your hinting at replacing global new/delete, which almost always works but only almost as Eugene explained. > And how would the ability help you if > you want to use a third party library that has signatures of the form > > void f(function const & g); Yep, no luck here. [snip] > I won't even go into details like whether std::allocator's interface > is suited for the task or whether the function<>'s specification as it > currently stands gives you any guarantees for deterministic behavior. I didn't say std::allocator is perfect, but it's standard ;-). function's spec indeed doesn't guarantee determinism, but I couldn't think of a reasonable implementation that isn't deterministic. Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
On Tuesday, Aug 26, 2003, at 10:41 America/Denver, 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 sp_counted_base_impl. I think it would be great. Then I suggest giving it a try. However there is another problem. You have to new your object. shared_ptr s( new MyClass ); You cannot use allocator like you would expect: shared_ptr< MyClass, std::allocator > s; Right. The shared_ptr design carefully avoids any extra class template parameters, in favor of parameterizing the constructor. My idea, if it works, would be to specialize sp_counted_base_impl on the pointer type P, e.g. MyClass*, so you just write shared_ptr s( new MyClass ); or on the deleter type D, so you would write, e.g. shared_ptr s( new MyClass, MyDeleter> ); The idea is that your sp_counted_base_impl specialization provides a custom operator new and operator delete that uses your allocator. Alternatively, we could consider adding shared_ptr constructor that takes an allocator argument. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: enable_if formal review ?
David Abrahams wrote: Thomas Witt <[EMAIL PROTECTED]> writes: - - A full boost-conformant implementation is available in the sandbox Or in Boost CVS, I hope... since if it's already in use it may already be there. I assume that in general the new component would have a new place and add some tweaks. Furthermore I would not want to make a general exception to the review-first-boost-CVS-then idea. That being said, something that is in boost CVS already doesn't need to be moved to sandbox for review purposes. - - The submitter posts an fasttrack review announcement to the list (should this go to boost-announce as well?). Review period should last for 5 days. No two fasttrack review should run in parallel. Fasttrack review may run during full reviews, though generally this should be avoided. No review manager intervention at all? Yep this is going to be lightweight process. If it doesnt play out we can change it accordingly. Hmm, I'd rather you make the announcement. I can check the preconditions and do the scheduling as well as the announcement, if you want me to. Thomas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
On Tuesday 26 August 2003 01:23 pm, Peter Dimov wrote: > Leaving aside the issue of whether specializing std::allocator is > a good idea: > > shared_ptr< MyClass, MyAllocator > s; > > note that you now wouldn't be able to pass s to a function that expects > shared_ptr since the type is not the same. There's no reason shared_ptr couldn't support a constructor that takes an allocator as an argument. Then sp_counted_base_impl would also take an Allocator parameter (heh, the allocator it was in fact allocated with) and would know how to deallocate itself via a (copy of) this allocator. We'd get allocator support without putting the allocator into the type of shared_ptr (just like we have deleter support). Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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 >> sp_counted_base_impl. > > I think it would be great. > > However there is another problem. > You have to new your object. > shared_ptr s( new MyClass ); You can allocate your object however you want: shared_ptr s(MyClass::allocate(), MyClass::deallocate); and of course there is also the textbook way of defining a suitable MyClass::operator new. > You cannot use allocator like you would expect: > shared_ptr< MyClass, std::allocator > s; Leaving aside the issue of whether specializing std::allocator is a good idea: shared_ptr< MyClass, MyAllocator > s; note that you now wouldn't be able to pass s to a function that expects shared_ptr since the type is not the same. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
Thomas Witt <[EMAIL PROTECTED]> writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Jaako, > > Jaakko Jarvi wrote: > > | Hi Boosters, > | > | We submitted enable_if for formal review in July. The library does not > | seem to be on the review queue, > > It is in fact in the queue, only that the queue is only current in CVS. Thomas, if you do not have write permission on the Boost website, email me in private and I'll send you the password so you can update the site at will. > | and maybe it is not worth a full > | review. > > Let's introduce a fasttrack review for this kind of utility components > criteria and procedure will be as follows. > > What components qualify for a fasttrack review > - - > > - - The technique must be already in use in boost libraries > ~ thus the new component provides a common implementation > > - - The component must be small > > Procedure > - - > > - - A full boost-conformant implementation is available in the sandbox Or in Boost CVS, I hope... since if it's already in use it may already be there. > - - The submitter posts an fasttrack review announcement to the list > (should this go to boost-announce as well?). Review period should last > for 5 days. No two fasttrack review should run in parallel. Fasttrack > review may run during full reviews, though generally this should be avoided. No review manager intervention at all? Hmm, I'd rather you make the announcement. > - - After the review period ended, the submitter will post a review > summary containing planned changes to the current implementation. > > - - After applying all changes, the component will be checked in to cvs by > the submitter. > > If nobody objects, I'll add this to our review policies. > > Thomas > > Boost Review Wizard. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
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. There is no original object after the move, only raw storage. > > ...which is a different meaning from move in our move proposal Most definitely. "Our" move writes to the source, memcpy_move does not since, well, memcpy doesn't. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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 > sp_counted_base_impl. I think it would be great. However there is another problem. You have to new your object. shared_ptr s( new MyClass ); You cannot use allocator like you would expect: shared_ptr< MyClass, std::allocator > s; Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
"Patrick Kowalzick" <[EMAIL PROTECTED]> writes: > Hi Matthew, > > I like these statistics. Nice graphs. > > Did you test the block_prod compared to normal prod as well ? This would be > interessting compared to ATLAS as well. It's very hard to read, IMO. It's not clear what the lines are referring to and some of them look too similar to be distinguished. > Regards, > Patrick > > "Hurd, Matthew" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> > From: Firingme [mailto:[EMAIL PROTECTED] >> >> > I'm a newbie to uBlas , but have used MTL for a long time. >> > Before I learned MTL, I've founded MTL's performance result >> > graph data on the following URL: >> > >> > http://www.osl.iu.edu/research/mtl/performance.php3 >> > >> > Now, is there any performance result data about uBlas ? >> > >> This is one of the better sources of results... >> >> http://www.opencascade.org/upload/87/index.html >> >> There is a small chart I did a while back at >> http://groups.yahoo.com/group/Boost-Users/files/ >> Called uBLA performance. >> >> HTH, >> >> Matt. >> ___ >> Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >> > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
> 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.
I agree. It means the STL is not consistent either.
So what are the boost recomendations for using STL containers and boost
in the same class?
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< typename T >
struct A
{
shared_ptr _data;
std::list _list;
};
template< typename T, template A = std::allocator >
struct A
{
shared_ptr _data;
std::list _list;
A : _data( new T() ) {...}
};
The problem with the first defenition is that I am limiting the built-in STL
functionality in
terms of memory management.
The problem with the second definition is that if I expose the allocator template
parameter, the
user of my class will expect that all memory allocations of type T are going to be
using her
allocator but boost::shared_ptr doesn't support it.
Could you please advise me?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
"Neal D. Becker" <[EMAIL PROTECTED]> writes: > On Saturday 23 August 2003 07:18 am, John Maddock wrote: >> > One more thing: what exactly can go wrong with 1.30.0 if >> > -pthread isn't used? Is it boost specific or a general thing >> > (e.g. issues w/ respect to libstdc++)? >> >> A general thing - without this then: >> >> Your std lib is not thread safe. >> Your C lib is not thread safe. >> g++ will not emit thread safe exception handling code. >> >> Thus while for C programs enabling thread support is just a question of >> linking to the right libraries, for C++ you also need to ensure that the >> compiler "knows" that you want thread safe code. >> > > You mean I can't just run bjam with no options and get the libs built with > thread support? I need to add a command-line option? The libraries that require thread support will be built with thread support. The others will not, unless multi has been placed in their default-build settings; single is the global default. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"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. There is no original object after the move, only raw storage. ...which is a different meaning from move in our move proposal -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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 sp_counted_base_impl. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [bind] result type deduction/access?
Mat Marcus wrote: It is not uncommon to use boost::function to hold on to the result of boost::bind. Will that work for you? Wrote it, compiled it and it worked immediately. Thanks very much! :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Regex compilation errors with BCB5
On Mon, 25 Aug 2003 14:31:07 +1000, Chris Trengove
<[EMAIL PROTECTED]> wrote:
At the moment, Boost.Regex has an incompatibility with the VCL headers
when
compiling with Borland C++ 5.5. Simply having
#include
#include
generates a large number of errors of the type.
[C++ Error] cregex.hpp(91): E2015 Ambiguity between '_fastcall operator
|(int,const Variant &)' and '|'
I'm afraid that I have yet to track down the precise cause of the errors,
or
a solution.
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)
For example the code below
//-Start of code
enum SquareAngle
{
Rotate0,
Rotate90,
Rotate180,
Rotate270,
Rotate360
} ;
SquareAngle operator*(SquareAngle lhs, SquareAngle rhs)
{
return static_cast((static_cast(lhs) +
static_cast(rhs)) %
static_cast(Rotate360)) ;
}
#include
#pragma hdrstop
#include "OperatorOverloadForm.h"
//--
-
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//--
-
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//End of code
produces the following error:
[C++ Error] sysset.h(24): E2015 Ambiguity between '_fastcall operator
/(int,const Currency &)' and '/'
plus others...
Any workarounds? I sbstituted the operator*() with a normal function...
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [bind] result type deduction/access?
It is not uncommon to use boost::function to hold on to the result of
boost::bind. Will that work for you?
- Mat
--On Tuesday, August 26, 2003 4:17 PM +0200 Daniel Frey
<[EMAIL PROTECTED]> wrote:
In my current project, there are a lot of code fragments that read
like this:
result->insert( "positions",
positions_.begin(),
positions_.end(),
bind( &Position::serialize,
_1,
boost::cref( locale ) ) );
The scheme is always the same, all that varies is the name of the
serialized class. Thus I wanted to write a helper:
result->insert( "positions",
positions_.begin(),
positions_.end(),
serializer< Position >( locale ) );
But the problem is, that AFAIK I have no (documented) way to specify
the result type of such a helper function. The syntax I would
imagine basically looks like this:
template< typename T >
typename Bind< &T::serialize, _1_type,
boost::reference_wrapper< const Base::Locale > >::result_type
serializer( const Base::Locale& locale ) {
return bind( &T::serialize, _1, boost::cref( locale ) );
}
Is something like that possible? I hope so, but I guess I'm not the
expert to understand all the details involved in the bind-internals.
The above is just an idea, of course it might look different in
practice. The question is, whether we can create some mapping
between the call of the bind-function and a provider for the result
type that users can understand without looking into the code of bind
itself.
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
Hi Matthew, I like these statistics. Nice graphs. Did you test the block_prod compared to normal prod as well ? This would be interessting compared to ATLAS as well. Regards, Patrick "Hurd, Matthew" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > From: Firingme [mailto:[EMAIL PROTECTED] > > > I'm a newbie to uBlas , but have used MTL for a long time. > > Before I learned MTL, I've founded MTL's performance result > > graph data on the following URL: > > > > http://www.osl.iu.edu/research/mtl/performance.php3 > > > > Now, is there any performance result data about uBlas ? > > > This is one of the better sources of results... > > http://www.opencascade.org/upload/87/index.html > > There is a small chart I did a while back at > http://groups.yahoo.com/group/Boost-Users/files/ > Called uBLA performance. > > HTH, > > Matt. > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [bind] result type deduction/access?
In my current project, there are a lot of code fragments that read like
this:
result->insert( "positions",
positions_.begin(),
positions_.end(),
bind( &Position::serialize,
_1,
boost::cref( locale ) ) );
The scheme is always the same, all that varies is the name of the
serialized class. Thus I wanted to write a helper:
result->insert( "positions",
positions_.begin(),
positions_.end(),
serializer< Position >( locale ) );
But the problem is, that AFAIK I have no (documented) way to specify the
result type of such a helper function. The syntax I would imagine
basically looks like this:
template< typename T >
typename Bind< &T::serialize, _1_type,
boost::reference_wrapper< const Base::Locale > >::result_type
serializer( const Base::Locale& locale ) {
return bind( &T::serialize, _1, boost::cref( locale ) );
}
Is something like that possible? I hope so, but I guess I'm not the
expert to understand all the details involved in the bind-internals. The
above is just an idea, of course it might look different in practice.
The question is, whether we can create some mapping between the call of
the bind-function and a provider for the result type that users can
understand without looking into the code of bind itself.
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] enable_if formal review ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jaako, Jaakko Jarvi wrote: | Hi Boosters, | | We submitted enable_if for formal review in July. The library does not | seem to be on the review queue, It is in fact in the queue, only that the queue is only current in CVS. | and maybe it is not worth a full | review. Let's introduce a fasttrack review for this kind of utility components criteria and procedure will be as follows. What components qualify for a fasttrack review - - - - The technique must be already in use in boost libraries ~ thus the new component provides a common implementation - - The component must be small Procedure - - - - A full boost-conformant implementation is available in the sandbox - - The submitter posts an fasttrack review announcement to the list (should this go to boost-announce as well?). Review period should last for 5 days. No two fasttrack review should run in parallel. Fasttrack review may run during full reviews, though generally this should be avoided. - - After the review period ended, the submitter will post a review summary containing planned changes to the current implementation. - - After applying all changes, the component will be checked in to cvs by the submitter. If nobody objects, I'll add this to our review policies. Thomas Boost Review Wizard. - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/S2jB0ds/gS3XsBoRAgE8AJ0fPp7LS8DBg40OrGrR+pa/bkXYfgCfednm RUDdbbSxF1x1SFTXSDGjGvI= =yjEu -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
On Sat, 23 Aug 2003, John Maddock wrote: > > > One more thing: what exactly can go wrong with 1.30.0 if > > -pthread isn't used? Is it boost specific or a general thing > > (e.g. issues w/ respect to libstdc++)? > > A general thing - without this then: > > Your std lib is not thread safe. > Your C lib is not thread safe. > g++ will not emit thread safe exception handling code. > > Thus while for C programs enabling thread support is just a question of > linking to the right libraries, for C++ you also need to ensure that the > compiler "knows" that you want thread safe code. IMHO it's not requirement to use -pthread on linux - especially when it's not documented. I think usage of -D_REENTRANT for compiling and -lpthread for linking should be enough. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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++ community has been trained to take for granted that it's perfectly acceptable for the system allocator to not work well. It does not _have_ to be this way. If you can write a better allocator, so can they. Of course things aren't that simple since the general allocator can not afford the luxury to only handle one particular application's memory use pattern. On the other hand, per-project allocators are usually written under pressure, not tested well, have bugs, so the playing field is fairly even. :-) Many project specific allocators I have seen can't even match dlmalloc, let alone a native commercial replacement. > 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 be supported by a portable mechanism affecting the interface. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Problem on the CVS version of the top web page
We do a regular merge of branch changes into HEAD in our source at work. So far I've had a sum-total of 1 conflict... Things to remember when merging: * where possible ignore whitespace * suppress keyword expansion * keep your sync tags well documented I based our process at work on the following document: http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/Attic/README.SMP?re v=1.1.2.9&content-type=text/plain&only_with_tag=SMP (you're probably going to have to paste that back together) We used to have a huge problem with bringing changes from one version into another (missing code etc.), but the semi-automated merge process is much more reliable. One word of warning: committers should think carefully about what they put in commit messages. The person doing the merge can resolve conflicts more easily if the changes (and their intent) is well documented. /Michael -Original Message- From: Janusz Piwowarski [mailto:[EMAIL PROTECTED] Sent: 24 August 2003 06:50 To: Boost mailing list Subject: Re: [boost] Re: Problem on the CVS version of the top web page On Sunday, August 24, 2003, 7:15:11 AM, Daryle Walker wrote: > I have a "CVS Quick Reference Card" lying around, and the entries for > "checkout" and "update" have a sub-option "-j REV" that says "Merge in > changes". That can't fuse one branch into another? (I wouldn't want > to potentially hose our CVS experimenting with this. Any experts out > there that know what this sub-option does?) You're right, -j option with update command can merge changes between branches. It works ok, marks places changed in both branches with standard cvs markers and . Regards, Janusz ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost Integer Library] compilation patch for NetBSD
Dear all, attached is a patch to integer_traits.hpp, enabling it to be compiled under NetBSD. Kind regards, Angus Index: boost/integer_traits.hpp === RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/integer_traits.hpp,v retrieving revision 1.11 retrieving revision 1.12 diff -u -p -r1.11 -r1.12 --- boost/integer_traits.hpp 7 Aug 2003 12:09:23 - 1.11 +++ boost/integer_traits.hpp 23 Aug 2003 10:07:08 - 1.12 @@ -99,13 +99,14 @@ class integer_traits #elif (defined(__sgi) && (!defined(__SGI_STL_PORT) || __SGI_STL_PORT < 0x400))\ || (defined __APPLE__)\ || (defined(__OpenBSD__) && defined(__GNUC__))\ +|| (defined(__NetBSD__) && defined(__GNUC__))\ || (defined(__FreeBSD__) && defined(__GNUC__))\ || (defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 3) && !defined(__SGI_STL_PORT)) // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as int. // - SGI MIPSpro with native library // - gcc 3.x on HP-UX // - Mac OS X with native library -// - gcc on FreeBSD +// - gcc on FreeBSD, OpenBSD and NetBSD public detail::integer_traits_base #elif defined(__hpux) && defined(__GNUC__) && (__GNUC__ == 2) && !defined(__SGI_STL_PORT) // No WCHAR_MIN and WCHAR_MAX, wchar_t has the same range as unsigned int. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
On Saturday 23 August 2003 07:18 am, John Maddock wrote: > > One more thing: what exactly can go wrong with 1.30.0 if > > -pthread isn't used? Is it boost specific or a general thing > > (e.g. issues w/ respect to libstdc++)? > > A general thing - without this then: > > Your std lib is not thread safe. > Your C lib is not thread safe. > g++ will not emit thread safe exception handling code. > > Thus while for C programs enabling thread support is just a question of > linking to the right libraries, for C++ you also need to ensure that the > compiler "knows" that you want thread safe code. > You mean I can't just run bjam with no options and get the libs built with thread support? I need to add a command-line option? I am updating my RPM package for 1.30.2, and I'd like to make sure this is correct, and I will forward this to Redhat (they now have a boost rpm). pgp0.pgp Description: signature
Re: [boost] Re: Re: what happened to allocators in boost?
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 must inevitably have a separate heap > for each possible object size. The difficult part is reserving enough > slots in each heap at startup, before deterministic reaction is necessary. I don't > see how a system could do this automatically when memory is scarce. The usual approach is to borrow an entry from the 2*N heap and split it in two when the N heap is empty. Most contemporary allocators do maintain per-size buckets for small allocations even for non-realtime systems since this improves performance and reduces fragmentation dramatically. Even if the system allocator does not work for you, why would you want to only replace function<>'s allocator but leave all other allocations non-deterministic? And how would the ability help you if you want to use a third party library that has signatures of the form void f(function const & g); ? Remember that one of the main uses of function<> is to turn the template template void f(G g); into a non-template like the above, and non-templates can't have an allocator template parameter. I won't even go into details like whether std::allocator's interface is suited for the task or whether the function<>'s specification as it currently stands gives you any guarantees for deterministic behavior. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
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_copyable and memcpy_moveable can >> be right. > Can >> you give an example ? >> >> Also, "flagging it" introduces some more complication on the user's >> part. How would you propose the user do this ? > > He needs to take a look at the has_trivial_* traits: > > has_trivial_assign is roughly equivalent to memcpy_copyable > > 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. There is no original object after the move, only raw storage. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote:
> "Edward Diener" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Extremely dangerous and error prone. I can't even imagine a non-POD
>> type where flagging it for memcpy_copyable and memcpy_moveable can
>> be right.
> Can
>> you give an example ?
>>
> It is error prone but many other constructs are too.
>
> Example of moveable object:
>
> struct string_buffer {
> unsigned size;
>char* data; // allocated buffer
> };
According to my understanding, this is a POD type. It would be unnecessary
to flag this. But even for a POD type such as this, copying would lead to
errors if the char * data were dynamically allocated since a double delete
would probably be done. And adding a copy constructor to deal with it would
remove it from POD category and make your memcpy_copyable and
memcpy_moveable irrelevant for it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Regex compilation errors with BCB5
> At the moment, Boost.Regex has an incompatibility with the VCL headers
when
> compiling with Borland C++ 5.5. Simply having
>
> #include
> #include
>
> generates a large number of errors of the type.
>
> [C++ Error] cregex.hpp(91): E2015 Ambiguity between '_fastcall operator
> |(int,const Variant &)' and '|'
>
> I'm afraid that I have yet to track down the precise cause of the errors,
or
> a solution.
I can reproduce this with just:
#include
#include
No boost code necessary :-(
Even worse this reproduces the error as well:
#include
#pragma hdrstop
enum enum_t
{
one = 1,
two = 2
};
int test()
{
int a = one | two; // error
int b = one + two; // error
int c = (int)one & (int)two; // OK
return a & b; // OK
}
which doesn't look good at all...
Oh and the problem is present in Builder 6 as well.
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Regex compiler warnings
> Compilation of Boost.Regex using Borland C++ 5.5 currently gives a bunch of > "previous options and warnings not restored" messages. The culprit is > boost/regex/config/cstring.hpp where the lines Fixes are in cvs now. Thanks for reporting this. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
> see boost::is_POD. And has_trivial_copy has_trivial_assign has_trivial_destruct etc John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
>> > > 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_copyable and memcpy_moveable can be right. Can > you give an example ? > > Also, "flagging it" introduces some more complication on the user's part. > How would you propose the user do this ? He needs to take a look at the has_trivial_* traits: has_trivial_assign is roughly equivalent to memcpy_copyable I guess there is no equivalent to memcpy_moveable: but it looks rather dangerous, what state is the original object left in afterwards etc? In any case there is another promising approach to moveable objects proposed for the next standard (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [uBlas] Any Performance Resulst Data with uBlas?
> From: Firingme [mailto:[EMAIL PROTECTED] > I'm a newbie to uBlas , but have used MTL for a long time. > Before I learned MTL, I've founded MTL's performance result > graph data on the following URL: > > http://www.osl.iu.edu/research/mtl/performance.php3 > > Now, is there any performance result data about uBlas ? > This is one of the better sources of results... http://www.opencascade.org/upload/87/index.html There is a small chart I did a while back at http://groups.yahoo.com/group/Boost-Users/files/ Called uBLA performance. HTH, Matt. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
"Edward Diener" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Extremely dangerous and error prone. I can't even imagine a non-POD type
> where flagging it for memcpy_copyable and memcpy_moveable can be right.
Can
> you give an example ?
>
It is error prone but many other constructs are too.
Example of moveable object:
struct string_buffer {
unsigned size;
char* data; // allocated buffer
};
The user could then write:
template<> memcpy_moveable {
static bool moveable = true; // or defining some type or so
}
and container can detect moveability and use memcpy(). If type is not
flagged, memcpy() won't be used.
Usually strings, smart pointers, vectors, pimpls are memcpy moveable. Pimpl
with back pointer isn't.
(The memcpy_copyable<> is probably not that good idea and not much useful.)
/Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [uBlas] Any Performance Resulst Data with uBlas?
I'm a newbie to uBlas , but have used MTL for a long time. Before I learned MTL, I've founded MTL's performance result graph data on the following URL: http://www.osl.iu.edu/research/mtl/performance.php3 Now, is there any performance result data about uBlas ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
David Abrahams <[EMAIL PROTECTED]> writes: > > What about: > > > > assert( p.branch_path().empty() ); > > > > Isn't that closer to what you are trying to express? > > I guess so. I didn't see branch_path(). BTW, it would feel much more natural to me if it were path root() const; path branch() const; path leaf() const; but because of the portable-ization of non-portable windows path constructs, I think something this simple is impossible. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
Beman Dawes <[EMAIL PROTECTED]> writes: > At 03:55 PM 8/21/2003, David Abrahams wrote: > > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> At 08:31 PM 8/19/2003, David Abrahams wrote: > >> > > >> >It surprised me a bit that leaf returns a string instead of a path. > >> > >> The rule isn't entirely obvious. If a decomposition function can > >> possibly return more that one element, it is returned as type path. If > >> at most a single element is returned, the return type is std::string. > > > >It may not surprise you, but the easy translation between paths and > >strings really rubs me the wrong way. Practically the only reason I'm > >using the path class at all is to increase the level of abstraction > >and self-documentation of the code I'm writing -- I think it's foolish > >to pass around something called std::string when it really represents > >a file path. A single component of a path is still a path, and it > >shouldn't devolve into a string. > > > >I'm rewriting some Java code in C++ which has a "Directory" > >abstraction, that lets you open files in that directory. I want those > >functions take path parameters. I want to assert that they're leaf > >paths. Having to write: > > > >assert(path(p.leaf()) == p) > > > >or > > > > assert(p.leaf() == p.string()) > > > >instead of: > > > > assert(p == p.leaf()) > > > >really feels odd to me. > > What about: > > assert( p.branch_path().empty() ); > > Isn't that closer to what you are trying to express? I guess so. I didn't see branch_path(). > >> >Shouldn't > >> > > >> > "foo/bar"/p.leaf() > >> > > >> >work? > >> > >> Yes, via the automatic conversion. I just added a test case to > >> path_test to verify that. Yes, it does work. I expect there would > >> have been scads of bug reports if it didn't work. > > > >Whoa. What code and compiler did you test that with? > > Ah! I corrected your code first so that "foo/bar" was a path. There is > no operator/ for string arguments, of course. Of course; that was the point of what I was saying. you can write cstring/path, but not cstring/std::string; I think it's reasonable to combine the leaf of a path with path strings if that's something you can normally do with a full path. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: path::leaf()
"Rainer Deyke" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Rainer Deyke" <[EMAIL PROTECTED]> writes:
>>
>>> David Abrahams wrote:
A single component of a path is still a path, and it
shouldn't devolve into a string.
>>>
>>> I disagree. While a path with just one component can exist, a
>>> single path component is no more a path than an element in an array
>>> of integers is itself an array of integers.
>>> A single component of a path is a name, and therefore naturally
>>> represented by 'std::string'.
>>
>> Are you seriously saying that path("foo") is not a path?
>
> No. "foo" is a path element. path("foo") is a path with one element.
>
>> If you want
>> to make paths into containers of strings, give them iterators and
>> operator[], and I'll accept the name back() as a way to get the leaf
>> string.
>
> Paths already have iterators to iterate over the path elements. I agree
> that 'back' would be a better name what is currently called 'leaf', since
> this frees the 'leaf' name to return a path instead of a string.
>
>>> If 'p' is a native path
>>
>> Is there such a thing as a "native path"? I thought all path strings,
>> even if they began as native, got converted immediately into some
>> "portable generic" format internally.
>
> It is my understanding that paths are implemented as
> std::vector or something similar, where the individual
> strings can contain slashes if the underlying filesystem allows it.
> It would be a shame if filesystem::path was unable to represent
> legal native paths just because they contain characters which have
> special meaning in the portal path grammar.
>
>>> then 'p.leaf()' may contain any character that is supported by the
>>> native file system, which may include slashes. When 'p.leaf()' is
>>> then converted back into a 'filesystem::path', the resulting path
>>> will have different sematics than intended. This strikes me as very
>>> dangerous.
>>
>> Oh, is that what happens now? Yipes!
>
> Yipes indeed.
I am finding Rainer's arguments quite convincing. Beman, what do you
think about this?
Also, his last point makes me think that perhaps path ought to have
push_back so we can *add* an element with a slash in it.
If a path really *is* a container of strings, I have no problem with
having functions which build paths by parsing strings in various ways,
but it seems like those functions don't belong in the path
constructor. What about, simply:
struct path : std::vector
{
// forwarding constructors
};
??
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
Pavel Vozenilek wrote: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > ... >> >> I don't believe you can use memcpy to move any non-POD types >> portably, >> i.e. without special knowledge of the compiler. >> > 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_copyable and memcpy_moveable can be right. Can you give an example ? Also, "flagging it" introduces some more complication on the user's part. How would you propose the user do this ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: path::leaf()
At 03:55 PM 8/21/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> At 08:31 PM 8/19/2003, David Abrahams wrote: >> > >> >It surprised me a bit that leaf returns a string instead of a path. >> >> The rule isn't entirely obvious. If a decomposition function can >> possibly return more that one element, it is returned as type path. If >> at most a single element is returned, the return type is std::string. > >It may not surprise you, but the easy translation between paths and >strings really rubs me the wrong way. Practically the only reason I'm >using the path class at all is to increase the level of abstraction >and self-documentation of the code I'm writing -- I think it's foolish >to pass around something called std::string when it really represents >a file path. A single component of a path is still a path, and it >shouldn't devolve into a string. > >I'm rewriting some Java code in C++ which has a "Directory" >abstraction, that lets you open files in that directory. I want those >functions take path parameters. I want to assert that they're leaf >paths. Having to write: > >assert(path(p.leaf()) == p) > >or > > assert(p.leaf() == p.string()) > >instead of: > > assert(p == p.leaf()) > >really feels odd to me. What about: assert( p.branch_path().empty() ); Isn't that closer to what you are trying to express? >> >Shouldn't >> > >> > "foo/bar"/p.leaf() >> > >> >work? >> >> Yes, via the automatic conversion. I just added a test case to >> path_test to verify that. Yes, it does work. I expect there would >> have been scads of bug reports if it didn't work. > >Whoa. What code and compiler did you test that with? Ah! I corrected your code first so that "foo/bar" was a path. There is no operator/ for string arguments, of course. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
