[boost] Re: Boost.Regex compilation errors with BCB5
"John Maddock" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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.
No, it doesn't look good at all, but when I try the above two tests, the
compiler behaves for me (both Builder 5 and 6). I can even have
enum enum_t {
one = 1,
two = 2,
three = one | two
};
and I don't get an error. Are you using any particular compiler setting?. (I
am just creating a new Console Project in the IDE and then pasting in the
code.) Maybe there is more to this?
Chris
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
Zing! /* * Chris Cooney * Ventana Group * [EMAIL PROTECTED] * (530)846-6640 x201 **/ CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, save, distribute or take action in reliance upon this message. If you have received this in error, please notify the sender immediately by return email and immediately delete this message and any attachment(s) from your email. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Abrahams Sent: Tuesday, August 26, 2003 4:38 PM To: Boost mailing list Subject: [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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
Then Matthew, refer to your graph result data, the champion and the runner-up all are C libs but not C++ .. Does it means if I want to get high performance with Matrix operation, I "must" use C but not C++ ___ 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.
Peter, using your example I put together an allocator class that can be used in
shared_ptr and STL
at the same time. It is not too pretty but it works. If we could only customize the
counter
allocations, that would be it.
namespace boostx
{
template< typename A >
class allocator : public A
{
public:
typedef A::value_type type;
allocator() {}
type* create()
{
type* p = allocate(1, 0);
try
{
p = new(p) type;
}
catch(...)
{
deallocate( p, 1 );
throw;
}
return p;
}
void operator()( type* p )
{
try
{
p->~T();
}
catch(...)
{
deallocate(p, 1);
throw;
}
deallocate(p, 1);
}
};
};
template < class T, class A = boostx::allocator< std::allocator > >
struct X
{
boost::shared_ptr _data;
std::vector _list;
X( const A& al = A() ) : _list(al)
{
A tmp(al);
_data = boost::shared_ptr( tmp.create(), tmp );
}
};
OR if you don't mind dropping the 'const' from the constructor
template < typename T, class A = boostx::allocator< std::allocator > >
struct X
{
boost::shared_ptr _data;
std::vector _list;
X( A& al = A() ) : _list(al), _data( al.create(), al )
{
}
};
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" <[EMAIL PROTECTED]> wrote:
>
> --- 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.
>
> Peter, using your example I put together an allocator class that can be used in
> shared_ptr and
> STL
> at the same time. It is not too pretty but it works. If we could only customize
> the counter
> allocations, that would be it.
>
> namespace boostx
> {
> template< typename A >
> class allocator : public A
> {
> public:
> typedef A::value_type type;
> allocator() {}
>
> type* create()
> {
> type* p = allocate(1, 0);
> try
> {
> p = new(p) type;
> }
> catch(...)
> {
> deallocate( p, 1 );
> throw;
> }
> return p;
> }
>
> void operator()( type* p )
> {
> try
> {
> p->~T();
> }
> catch(...)
> {
> deallocate(p, 1);
> throw;
> }
> deallocate(p, 1);
> }
> };
> };
>
> template < class T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( const A& al = A() ) : _list(al)
> {
> A tmp(al);
> _data = boost::shared_ptr( tmp.create(), tmp );
> }
> };
>
> OR if you don't mind dropping the 'const' from the constructor
>
> template < typename T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( A& al = A() ) : _list(al), _data( al.create(), al )
> {
> }
> };
>
>
> Eugene
I forgot to mention, if the 'const' is dropped from the constructor, 'A' must be
stateless.
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: what happened to allocators in boost?
"E. Gladyshev" <[EMAIL PROTECTED]> writes: > 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. Is it really (other than culturally, I mean)? Are you sure that there's no good general-purpose allocator which they can use? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
> -Original Message- > From: Firingme [mailto:[EMAIL PROTECTED] > Subject: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas? > > > Then Matthew, refer to your graph result data, the champion > and the runner-up all are C libs but not C++ > .. Does it means if I want to get high > performance with Matrix operation, I "must" use C but not C++ I don't know, I just did a graph. I'm have no expertise here. I have some personal thoughts about uBLAS and C++ numerics, but take it with a grain of salt. uBLAS performance - It is pretty good. Blocking was taken out the out of cache dead horse problem. But it is still significantly slower than vendor BLAS and ATLAS. Tv-met and the like are faster for small matrices, like the 4x4 transform you might use in CGI. Joerg has shown me some uBLAS results a while ago that were preliminary, unconfirmed and very fast for the Intel platform. Faster than ATLAS. So watch that space. You need a smart compiler with the appropriate settings to get good performance. Vectorising with SSE2 makes an enormous difference, for example, with Linux or Win32 on a P4. There is an issue with making the best performance available to everyone without the you-beaut compiler. Building and releasing libs/dlls for platforms would be required, which is not normal Boost practice. uBLAS as an interface - Works well. Nice interface. Can use ATLAS, vendor BLAS and other libs from this base. Would be good if there was an ATLAS-like automagically tuned interface for uBLAS to choose at compile and/or run time the appropriate underlying implementation for "prod" etal. That way uBLAS would transparently be using the best implementation, perhaps its own, at various points. This would mean that you could use uBLAS without any uncertainty that your performance will be superseded, encouraging numeric development beyond plain BLAS. The uBLAS guys have a LAPACK binding in progress as well. LAPACK, as you probably know, needs BLAS. Other bindings would be good to encourage uBLAS as the lingua franca of numeric C++. On the flip side, a lot of uBLAS work will be ignored unless it can be incorporated into other works, like LAPACK. I think this means that uBLAS should provide a BLAS interface so that people are encourage to work within the framework of uBLAS knowing that this is a widely useful thing. Again this could grow to include other interfaces, e.g. uLAPACK, to encourage and draw resources. Developing right now What would I do right now? I would use uBLAS and delegate to ATLAS or a vendor BLAS where that really mattered. That's what I do. I'd suggest you to talk to the ublas-dev list and get information from horses' mouths. They have been nice guys to chat to. Regards, HTH. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- "E. Gladyshev" <[EMAIL PROTECTED]> wrote:
>
> --- 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.
>
> Peter, using your example I put together an allocator class that can be used in
> shared_ptr and
> STL
> at the same time. It is not too pretty but it works. If we could only customize
> the counter
> allocations, that would be it.
>
> namespace boostx
> {
> template< typename A >
> class allocator : public A
> {
> public:
> typedef A::value_type type;
> allocator() {}
>
> type* create()
> {
> type* p = allocate(1, 0);
> try
> {
> p = new(p) type;
> }
> catch(...)
> {
> deallocate( p, 1 );
> throw;
> }
> return p;
> }
>
> void operator()( type* p )
> {
> try
> {
> p->~T();
> }
> catch(...)
> {
> deallocate(p, 1);
> throw;
> }
> deallocate(p, 1);
> }
> };
> };
>
> template < class T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( const A& al = A() ) : _list(al)
> {
> A tmp(al);
> _data = boost::shared_ptr( tmp.create(), tmp );
> }
> };
>
> OR if you don't mind dropping the 'const' from the constructor
>
> template < typename T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( A& al = A() ) : _list(al), _data( al.create(), al )
> {
> }
> };
Sorry, disregard my prev e-mail. I should have said that 'A' must always be stateless.
But then, what is the point passing the A& thing around...
I guess my solution is a limited one. It is hard to get around it w/o
a built-in allocator support.
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: what happened to allocators in boost?
--- David Abrahams <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > > > 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. > > Is it really (other than culturally, I mean)? The culture is changing. :) > Are you sure that > there's no good general-purpose allocator which they can use? Yes, I am sure. I shipped one of my libraries to a guy who works on various DSP chips. The native memory allocator on one of the DSP was very slow (some specific issues with how the DSP addresses the memory, I don't remember the details). This guy had to add his own new/delete operator to some of my internal classes to get about 10 times performance improvement. No, I really don't think that there is a hope for general purpose allocators. 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: Re: [uBlas] Any Performance Resulst Data with uBlas?
"Hurd, Matthew" <[EMAIL PROTECTED]> ??:[EMAIL PROTECTED] > > > -Original Message- > > From: Firingme [mailto:[EMAIL PROTECTED] > > Subject: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas? > > > > > > Then Matthew, refer to your graph result data, the champion > > and the runner-up all are C libs but not C++ > > .. Does it means if I want to get high > > performance with Matrix operation, I "must" use C but not C++ > > I don't know, I just did a graph. I'm have no expertise here. > > I have some personal thoughts about uBLAS and C++ numerics, but take it with > a grain of salt. > > uBLAS performance > - > > It is pretty good. Blocking was taken out the out of cache dead horse > problem. But it is still significantly slower than vendor BLAS and ATLAS. > Tv-met and the like are faster for small matrices, like the 4x4 transform > you might use in CGI. > > Joerg has shown me some uBLAS results a while ago that were preliminary, > unconfirmed and very fast for the Intel platform. Faster than ATLAS. So > watch that space. > > You need a smart compiler with the appropriate settings to get good > performance. Vectorising with SSE2 makes an enormous difference, for > example, with Linux or Win32 on a P4. There is an issue with making the > best performance available to everyone without the you-beaut compiler. > Building and releasing libs/dlls for platforms would be required, which is > not normal Boost practice. > > > uBLAS as an interface > - > > Works well. Nice interface. Can use ATLAS, vendor BLAS and other libs from > this base. > Would be good if there was an ATLAS-like automagically tuned interface for > uBLAS to choose at compile and/or run time the appropriate underlying > implementation for "prod" etal. That way uBLAS would transparently be using > the best implementation, perhaps its own, at various points. > > This would mean that you could use uBLAS without any uncertainty that your > performance will be superseded, encouraging numeric development beyond plain > BLAS. > > The uBLAS guys have a LAPACK binding in progress as well. LAPACK, as you > probably know, needs BLAS. Other bindings would be good to encourage uBLAS > as the lingua franca of numeric C++. > > On the flip side, a lot of uBLAS work will be ignored unless it can be > incorporated into other works, like LAPACK. I think this means that uBLAS > should provide a BLAS interface so that people are encourage to work within > the framework of uBLAS knowing that this is a widely useful thing. Again > this could grow to include other interfaces, e.g. uLAPACK, to encourage and > draw resources. > > > Developing right now > > > What would I do right now? I would use uBLAS and delegate to ATLAS or a > vendor BLAS where that really mattered. That's what I do. > > I'd suggest you to talk to the ublas-dev list and get information from > horses' mouths. They have been nice guys to chat to. > > Regards, > > HTH. > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > Where is uBlas-dev list ??? I can't find it ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
"E. Gladyshev" <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> "E. Gladyshev" <[EMAIL PROTECTED]> writes: >> >> > 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. >> >> Is it really (other than culturally, I mean)? > > The culture is changing. :) > >> Are you sure that >> there's no good general-purpose allocator which they can use? > > Yes, I am sure. I shipped one of my libraries to a guy who > works on various DSP chips. The native memory allocator > on one of the DSP was very slow (some specific issues with > how the DSP addresses the memory, I don't remember the details). > > This guy had to add his own new/delete operator to some of > my internal classes to get about 10 times performance improvement. None of that indicates that he couldn't have replaced the native allocator with a fast general-purpose allocator. > No, I really don't think that there is a hope for general purpose > allocators. Why not? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: what happened to allocators in boost?
> -Original Message- > From: David Abrahams [mailto:[EMAIL PROTECTED] > > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > > 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. > > Is it really (other than culturally, I mean)? Are you sure that > there's no good general-purpose allocator which they can use? What is general purpose? does general purpose include (presumably all at once as iiuyc "there can be only one"): Determinism. Memory usage efficiency. Ability to share allocated objects between threads. Low/no impact on scheduling latency. Speed. Freedom from fragmentation over an arbitrarily long uptime (years). Bonus marks for the last on systems with no mmu. Policy based allocators anyone? But then, I'd probably wan't (need?) policy based smart pointers to use the allocators with. At least some of the above conflicting requirements imply policy decisions about the pointers to this storage. The low latency, but no sharing between threads allocator rather implies that managing the object lifetime using a thread-safe shared_ptr is inefficient at best and dangerous at worst - including the allocator in the type wouldn't be a bad thing here. That suggests to me that policy based smart pointers are the way to go for some (all?) such users/uses. I don't think this in any way detracts from the utility of boost::shared_ptr<> as it stands - a lot of the time, I just "want it to work". Nevertheless there are systems for which which I can't/won't use it (at least not until I've had a chance to digest Peter Dimov's suggestions better). Just one user opinion - ymmv. Regards Darryl Green. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: [uBlas] Any Performance Resulst Data with uBlas?
> From: Firingme [mailto:[EMAIL PROTECTED] > Where is uBlas-dev list ??? > I can't find it It is a yahoo groups thingo at: http://groups.yahoo.com/group/ublas-dev/ Check out http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Effective_UBL AS too. Cheers, Matt. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: what happened to allocators in boost?
Title: RE: [boost] Re: what happened to allocators in boost? --- David Abrahams <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > >> Are you sure that >> there's no good general-purpose allocator which they can use? > >Yes, I am sure. I shipped one of my libraries to a guy who >works on various DSP chips. The native memory allocator >on one of the DSP was very slow (some specific issues with >how the DSP addresses the memory, I don't remember the details). > >This guy had to add his own new/delete operator to some of >my internal classes to get about 10 times performance improvement. > >No, I really don't think that there is a hope for general purpose allocators. If it was a system wide performance problem on that DSP wouldn't he have been better off replacing the system allocator completely rather then only for a few classes? Glen
Re: [boost] Re: what happened to allocators in boost?
--- David Abrahams <[EMAIL PROTECTED]> wrote: > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > > > --- David Abrahams <[EMAIL PROTECTED]> wrote: > > Yes, I am sure. I shipped one of my libraries to a guy who > > works on various DSP chips. The native memory allocator > > on one of the DSP was very slow (some specific issues with > > how the DSP addresses the memory, I don't remember the details). > > > > This guy had to add his own new/delete operator to some of > > my internal classes to get about 10 times performance improvement. > > None of that indicates that he couldn't have replaced the native > allocator with a fast general-purpose allocator. > > > No, I really don't think that there is a hope for general purpose > > allocators. > > Why not? Sure he could have replaced the system allocator (I actually suggested it too) but why would he want to do it? The standard system allocator worked just fine for the rest of his program. Why would he want to implement a full blown memory manager. The problem was that my library had couple classes that get allocated/deleted very often it was the biggest performance hit. He just overloaded the new/delete in these classes and built a very simple fixed-size memory manager in a separate heap just for that. In fact a program might require different allocation strategies depending on the context. Replacing the global new/delete may not be an option. 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?
David Abrahams wrote: 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. What the hell is the matter with you? All I asked was how to set the multithreaded option. I looked in the documentation and couldn't find it. Are you too l33t to answer questions from mere users now? (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. Yeah yeah. Just keep taking the tablets, as the good Lord said to Moses. -- 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
[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
In article <[EMAIL PROTECTED]>, David Abrahams wrote: > "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. I recently ran into this trying to use shared_ptr in a mulithreaded app. The docs might be somewhat incomplete with regard to this. e.g. http://boost.org/more/download.html#Installation "preparing to use Boost in a development project is relatively straightforward. Most boost libraries are implemented entirely within their header files. The only preparation for their use is to add the boost root directory to your compiler's list of #include<...> search paths." http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety "shared_ptr uses Boost.Config to detect whether the implementation supports threads. If your program is single-threaded, but your platform is autodetected by Boost.Config as supporting multiple threads, #define BOOST_DISABLE_THREADS to eliminate the thread safety overhead." It wasn't immediately clear to me how to ensure that the linux app I am writing will always use the threadsafe version of shared_ptr (my app requires pthreads), no matter how/if the user configured boost. What I ended up doing was verifying pthread support at install time, and then defining BOOST_HAS_PTHREADS. Steve ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem on the CVS version of the top web page
On Sunday, August 24, 2003, at 6:49 PM, Janusz Piwowarski wrote: 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 . Would you start with a checked-out archive of the main trunk then apply "update -j" with the 1.30.x branch, or use a checked-out archive of the 1.30.x branch and apply "update -j" with the main trunk? We would want the results to be in the main trunk. Will the command tell us which files get the CVS markers, so we can fix them up before other people start downloading (hopefully)? What happens to binary files? Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem on the CVS version of the top web page
On Sunday, August 24, 2003, at 4:26 PM, David Abrahams wrote: Janusz Piwowarski <[EMAIL PROTECTED]> writes: 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 . That doesn't mean you can use it to correctly and automatically merge RC_1_30_0 into the trunk, because many cross-merges have already been made and there is no marker on the RC_1_30_0 branch to use with the first -j option. I don't know why anyone would want to try to make this simple change to the index page into a project which potentially touches every single file in the repository, anyway. I was thinking ahead to every file that had a change in 1.30.2 but wasn't yet in the main trunk. If most of the changes have been manually transferred already, then there is little point in doing a merging command. If we still have a lot of manual merging ahead of us, then automation could help. Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
On Monday, August 25, 2003, at 2:57 PM, Peter Dimov wrote:
E. Gladyshev wrote:
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
In this context, an allocator parameter is only an excuse for
implementors to avoid doing the necessary work to make function<>
useful out of the box. "You can always use a custom allocator",
right?
Considering the variety of real life requirements and platforms, it
is not practical to make a library that work out of the box.
The danger in that statement is that it looks obvious, but it's not.
It is true in some sotuations (not as frequent as is generally
believed) and false in others, and when it doesn't really hold but is
axiomatically accepted as truth, it serves as exactly the excuse I was
talking about. "It is not practical to make a library that works out
of the box, so users should be happy that they are getting a library
that can be made to work with a "small" additional investment. Of
course we'll gladly sell you the additional bits and pieces."
That's an invalid argument, since the STL containers give you a default
value for the allocator argument, which makes containers work out of
the box, and the default is "for free."
It is interesting to compare the C++ approach with the Java approach
to memory management in this context. C++ "pragmatically" accepts that
the shipped malloc is often inadequate and provides several types of
hooks that you can use to work around the problem. Java does not. If
the JVM has a broken memory manager you lose and can do nothing about
it. This gives C++ a short term advantage, but in the long term Java
wins, since JVM implementors have no choice but to optimize their
memory managers till they are blue in the face.
Bugs that have no workarounds are always fixed first. :-)
You're making a worse assumption here. Who says that the need for a
different allocator class is because the default one
has-bugs/is-slow/plain-old-sucks? There can be an orthogonal need for
a different allocator class, which no improvement on the default one
can fix.
In this case, the Java user is 100% screwed since they can't change the
memory manager at all. Or at least, can't change the manager without
changing it everywhere. (Allocator policies allow mix-and-match.)
That is why STL has allocators. In one project, if STL did not have
allocators, I would have to implement my own containers. I was so
happy that I didn't have to do it.
So far my experience indicates that people only bother with allocators
when std::allocator is inadequate, i.e. slow. Your case may, of
course, be different. It happens sometimes.
At least a library should be consistent about memory management.
This is an arbitrary requirement.
Taking a quick look at the Standard Library, all of the direct
containers that use dynamic memory take an allocator argument, except
for the maligned std::valarray<>.
The issue is how consistent boost is about it (STL is very
consistent)? It seems that boost doesn't have any idea about how it
manages its memory.
A fairly aggressive way to state it, but I see your point. It is true
that Boost does not impose any requirements on how the particular
libraries obtain and manage their memory. But you need to realize that
"do nothing" can be a conscious design decision. Lack of strict
requirements means more freedom for the implementations to do what
they consider best.
This last sentence is probably why std::valarray<> keeps its memory
policy private.
As an example, consider a hypothetical std::vector that does not
have an allocator argument and "has no idea how it manages its
memory." Do you see the implications of that?
1. vector::resize and vector::reserve can now realloc in place since
they can talk directly to the memory manager.
2. On many implementations, vector can now be made as efficient as
new T[], since new T[] often stores the equivalent of size() and
capacity() anyway to allow delete[] to do the right thing.
For example if a boost class X uses std::list, does it have to expose
the std::list<> allocator or should it use the standard
std::allocator<>.
template
struct X
{
std::list l;
};
OR
template >
struct X
{
std::list l;
};
Which definition is more friendly to boost?
The correct answer depends on X's interface. Your toy example is not a
good illustration as this kind of "interface" is rarely seen.
Is it allowed for a boost libarary to use global new/delete? If so,
should it be documented?
Boost libraries are allowed to use the C++ language without
restrictions.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Spirit question...
"Chris Cooney" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [...] > That was my problem - thank you. The moral being: Using anychar_p all by itself is usually a Bad Thing(TM) That's because it's like the langoliers--it eats everything up. You usually want to say what it shouldn't eat up by subtracting the terminating character from the parser. I think this is a Spirit FAQ. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [BGL] vector_as_graph::remove_vertex proposal
Hi Janusz,
Janusz Piwowarski wrote:
> I found remove_vertex member for vector_as_graph isn't implemented.
> It's my proposal:
Thanks!
> template
> void
> remove_vertex(typename EdgeList::value_type u,
> std::vector& g)
> {
> typedef typename EdgeList::iterator iterator;
> clear_vertex(u, g);
> g.erase(g.begin() + u);
> for (std::size_t i = 0; i < g.size(); ++i)
> for ( iterator it = g[i].begin(); it != g[i].end(); ++it )
> // after clear_vertex none *it is equal to u
> if ( *it > u )
> --*it;
> }
The implementation is fine, AFAICT. The only problem with me is the comment:
I couldn't understand it for the first time because "none *it" sounded
confusing. Maybe "*it is never equal to u" is better?
BTW, if you could sumbit unified diff instead of new implementation, that
would be nice. If that's not convenient for you, no problem. I can apply
the thange anyway.
Thanks,
Volodya
>
> Regards,
> Janusz
>
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [bgl] typo in adjacency_list_io.hpp
Hi Janusz, Janusz Piwowarski wrote: > Hi all > > gcc 3.2 generates warnings about implicit typename in line 313 in file > adjacency_list_io.hpp. I think either there should be EdgePrinter > call or class G should be renamed to Graph, as is in the rest of > templates in this file. Thanks for pointing this out. Changes to 'Graph'. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Spirit question...
David B. Held wrote: > The moral being: > > Using anychar_p all by itself is usually a Bad Thing(TM) > > That's because it's like the langoliers--it eats everything > up. You usually want to say what it shouldn't eat up by > subtracting the terminating character from the parser. I > think this is a Spirit FAQ. This isn't correct, sorry. The anychar_p parser used by itself isn't a bad thing, because it eats up only _one_ arbitrary character/token from the input stream, which may be very useful. The problematic part is the kleene_star operator, which requires some additional attention, because it "repeats" the attached parser zero or more times. So the kleene_star in conjunction with the anychar_p will eat up all your input sequence, regardless of what in contains. But this may happen with other attached parsers too. Regards Hartmut BTW: this kleene_star behaviour _is_ a FAQ, see here: http://www.boost.org/libs/spirit/doc/faq.html#kleene_star ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- Daryle Walker <[EMAIL PROTECTED]> wrote: > On Monday, August 25, 2003, at 2:57 PM, Peter Dimov wrote: > has-bugs/is-slow/plain-old-sucks? There can be an orthogonal need for > a different allocator class, which no improvement on the default one > can fix. > > In this case, the Java user is 100% screwed since they can't change the > memory manager at all. Or at least, can't change the manager without > changing it everywhere. (Allocator policies allow mix-and-match.) I am glad that boost is not a Java library. :) Don't get me wrong, boost is an amazing library. I am learning from it every minute I look at it, great job guys thank you. However I was a bit shocked when I realized how ignorant boost is about memory policies. For instance boost::signals use std::vector<>, but it doesn't care to do anything about the allocator parameter. Some libraries would mix global new/delete calls with user defined memory policies and all that under the covers and the list goes on and on. I don't like the STL allocators too much but I'd like to see a modern C++ library that has consistent and clear memory policies. Instead of having an allocator template parameter for each class, perhaps we could design a global memory management class that can be scaled horizontally on the data type basis. It will require some way to associate a user defined allocator with data type. Then we would need to define STL-style allocators that will call the boost memory manager. The boost memory policy could be along the lines: 1. All boost classes have to use boost::allocator<> with STL allocators internally. std::vector >; 2. If a boost class needs to create an object it must call boost::mm. int *x = boost::getmm()->create(1); ... boost::getmm()->destroy(x,1); 3. The user can customize memory policies for her class by calling regmm boost::getmm()->regmm( MyAllocator() ); IMHO, in terms of memory management, this simple policy will make boost to look more like a C++ library not Java. It doesn't provide the flexibility of STL allocators but it does give the user some control over the memory. 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: Spirit question...
David B. Held <[EMAIL PROTECTED]> wrote: > "Chris Cooney" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> [...] >> That was my problem - thank you. > > The moral being: > > Using anychar_p all by itself is usually a Bad Thing(TM) More accurately: Using *anychar_p or +anychar_p all by itself is usually a Bad Thing(TM) > That's because it's like the langoliers--it eats everything up. > You usually want to say what it shouldn't eat up by subtracting the > terminating character from the parser. I think this is a Spirit FAQ. It is now ;-) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [boost.optional && boost.variant] Why can't we allowreferences?
<< pardon me if this gets re-posted >> Hi, Is there a reason why we can't allow: optional opt; Also, is there a reason why we can't allow: variant var; IIUC, internally, it's just a matter of storing a boost.reference_wrapper if T is a reference. In as much as tuple is allowed, I see no reason why optional and variant can't allow references. Am I missing something? TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ 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?
>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). The thread libs will be built with threading support turned on (obviously), other libs will not be built thread safe by default - you could use bjam -sBUILD="multi" but remember that thread safe and non-thread-safe lib builds are very unlikely to be binary compatible (this is true of the C++ std lib as well BTW). We are aware that this is an issue, and there is work going on to provide an install procedure, that will address this by mangling library names. I hope we can provide an official rpm specs file as well, but that may have to wait... John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Regex compilation errors with BCB5
> and I don't get an error. Are you using any particular compiler setting?. (I > am just creating a new Console Project in the IDE and then pasting in the > code.) Maybe there is more to this? Make sure that the console app has "Project uses the VCL" checked when you create it. Haven't tried without it... I'm using the 5.6.4 compiler BTW. John. ___ 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?
> 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. Maybe - I don't have a linux box to check on right now - doing a: g++ -dumpspecs | grep thread will tell you what -pthread does on your system. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] what happened to allocators in boost?
Andreas Huber wrote: > > E.g. I hope to convince some of the embedded systems/real-time crowd > to use the fsm lib I'm currently implementing. I would bet that even > in 10 years most of them wouldn't even consider using it unless they > were able to totally control how memory is allocated... That's a good point, now we have something real to argue about. :-) I'm not that much into resource-constrained environments myself but from what I know, total control there is indeed the norm, and it is usually achieved by: 1. Banning all dynamic memory allocations and most (often all) third party libraries; or 2. Allowing dynamic memory and 3rd party libraries but replacing global new/delete (the starightforward C++ way to have total control.) I haven't heard of a case where 3rd party libraries are only allowed if they have an allocator parameter and where global new/delete are not taken over. It is very unnatural to replace "new X" with the allocator-based abomination everywhere in the code, and the benefits aren't that great to justify it. But it may be just my ignorance showing through, of course. This leads me to the obvious question: have you actually received a request to add an allocator parameter to the FSM library, or are you just second-guessing the requirements of the realtime programmers? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: what happened to allocators in boost?
"E. Gladyshev" <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> "E. Gladyshev" <[EMAIL PROTECTED]> writes: >> >> > --- David Abrahams <[EMAIL PROTECTED]> wrote: > >> > Yes, I am sure. I shipped one of my libraries to a guy who >> > works on various DSP chips. The native memory allocator >> > on one of the DSP was very slow (some specific issues with >> > how the DSP addresses the memory, I don't remember the details). >> > >> > This guy had to add his own new/delete operator to some of >> > my internal classes to get about 10 times performance improvement. >> >> None of that indicates that he couldn't have replaced the native >> allocator with a fast general-purpose allocator. >> >> > No, I really don't think that there is a hope for general purpose >> > allocators. >> >> Why not? > > Sure he could have replaced the system allocator (I actually suggested it too) > but why would he want to do it? > The standard system allocator worked just fine for the rest of his program. > Why would he want to implement a full blown memory manager. He would not. He would pick an off-the-shelf memory manager such as dlmalloc that has been shown to perform well in a wide variety of applications. > The problem was that my library had couple classes that get > allocated/deleted very often it was the biggest performance hit. He > just overloaded the new/delete in these classes and built a very > simple fixed-size memory manager in a separate heap just for that. > > In fact a program might require different allocation > strategies depending on the context. Replacing the global > new/delete may not be an option. Hypothetical or real? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
E. Gladyshev wrote: > > Sure he could have replaced the system allocator (I actually > suggested it too) but why would he want to do it? Because this saves time in the long run. Once you have a non-broken allocator you can use third party libraries as-is, without need for modification, and you can donate it to the community if you're after the fame (aren't we all.) > The standard system allocator worked just fine for the rest of his > program. Why would he want to implement a full blown memory manager. dlmalloc is not that hard to download. :-) Incidentally, you can #define BOOST_SP_USE_STD_ALLOCATOR or BOOST_SP_USE_QUICK_ALLOCATOR to tell shared_ptr to use std::allocator or boost::detail::quick_allocator for counts when your malloc is slow. But it's better to just replace the global new/delete so that every "new X" in the program benefits. And it's better yet to submit a "your malloc is slow, here's the link to dlmalloc which is five times faster on this real code" bug report. (BTW, "five times faster" is not a figure of speech. I do have real measurements. Had to let you know.) ___ 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?
Ross Smith <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> 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. > > What the hell is the matter with you? I was a bit miffed by your outraged response to my explanatory reply. I thought I was being helpful and instead I got "when did you stop beating your wife?" questions like #2 and #3 below. How is anyone supposed to answer those? > All I asked was how to set the multithreaded option. That question wasn't clear from your posting. As far as I could tell you were asking how to "just run bjam with no options and get the libs built with thread support". Maybe if you applied a little less heat it would be easier to help you. Sarcastic rhetoric may have hurt the comprehensibility of your request. http://www.boost.org/tools/build/build_system.htm documents how to set the build request on the command-line, and you can in fact find a mention of multi in there if you dig hard enough. > I looked in the documentation and couldn't find it. Are you too l33t > to answer questions from mere users now? Ask me a question which is more than just a way to vent your frustration and I'm happy to try to answer it. >>>(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. > > Yeah yeah. Just keep taking the tablets, as the good Lord said to Moses. Oh, so *that's* where the visions came from! ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem on the CVS version of the top web page
Daryle Walker <[EMAIL PROTECTED]> writes: > On Sunday, August 24, 2003, at 4:26 PM, David Abrahams wrote: > >> Janusz Piwowarski <[EMAIL PROTECTED]> writes: >> >>> 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 . >> >> That doesn't mean you can use it to correctly and automatically >> merge RC_1_30_0 into the trunk, because many cross-merges have >> already been made and there is no marker on the RC_1_30_0 branch to >> use with the first -j option. >> >> I don't know why anyone would want to try to make this simple change >> to the index page into a project which potentially touches every >> single file in the repository, anyway. > > I was thinking ahead to every file that had a change in 1.30.2 but > wasn't yet in the main trunk. If most of the changes have been > manually transferred already, then there is little point in doing a > merging command. If we still have a lot of manual merging ahead of > us, then automation could help. Most changes were made in the trunk first and then transferred to 1.30.2. A project-wide automated merge from branch to trunk would be a disaster. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Boost.Regex compilation errors with BCB5
"John Maddock" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Make sure that the console app has "Project uses the VCL" checked when you > create it. Haven't tried without it... I'm using the 5.6.4 compiler BTW. Yes, I am certainly doing this, and am also using 5.6.4 (and 5.5.1). Maybe you could email me your BPR and CPP files, and I can compare and see what is different. Chris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
Daryle Walker wrote: > > That's an invalid argument, since the STL containers give you a default > value for the allocator argument, which makes containers work out of > the box, and the default is "for free." I'm afraid it is not. The allocator parameter has a cost. It (a) prevents some very useful optimizations, (b) implementations that take it seriously (i.e. respect ::pointer, ::construct etc) make me suffer a measurable abstraction penalty. >> Bugs that have no workarounds are always fixed first. :-) > > You're making a worse assumption here. Who says that the need for a > different allocator class is because the default one > has-bugs/is-slow/plain-old-sucks? I say that the primary motivation to customize memory management details is that the default memory manager is slow. The standard allocators have a somewhat different story. They were originally intended to encapsulate the memory model, not the memory management details; this was in the near/far days. The original STL did its own memory management (free lists) independent of the allocator argument. Someone that has actually been present at the relevant meetings can fill the details why the allocators are now what they are (I'm tempted to use Alexander Terekhov's favorite characterization here :-)). > There can be an orthogonal need for a different allocator class, which no > improvement on the default one can fix. Oh yes, there "can be". And there "can be" a need for something else, too. > In this case, the Java user is 100% screwed since they can't change > the memory manager at all. [...] My point exactly. This is why the Java memory manager beats C++'s memory manager in the long run, because the user can't fix it. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem on the CVSversion of the top web page
[ I replied to Daryle, but his host said: 553 5.3.0 DNSBL:You are listed at relays.osirusoft.com :( ] > Would you start with a checked-out archive of the main trunk then > apply > "update -j" with the 1.30.x branch, or use a checked-out archive of > the > 1.30.x branch and apply "update -j" with the main trunk? We would > want > the results to be in the main trunk. You always update your local copy of repositorium, therefore it should be main trunk in this case. > Will the command tell us which files get the CVS markers, so we can > fix > them up before other people start downloading (hopefully)? Conflicts are reported during update process, besides files with conflicts are listed with "C" sign. > What > happens to binary files? I not sure, but i think conflict is reported. There is a good documentation on cvshome.org site, and second one on red-bean site (cvsbook.red-bean.com/cvsbook.html) Regards, Janusz ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Support Requests-795936 ] regex_matchproblem
Support Requests item #795936, was opened at 2003-08-27 05:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=207586&aid=795936&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: regex_match problem
Initial Comment:
Ruslan Talpa <[EMAIL PROTECTED]>
I want to match different strings in a whois result and i
am having some problems.
first a execut a shell command similar to:
"/usr/bin/whois domain.com > tmp_file"
so after this we have a file, from wich i read line by line
and try to match some strings but no matter what the
reg. expression is the regex_match returns false.
i even tried "regex expression("a");" and still no luck
The only thing i can think of is that there is some
character encoding stuff envolved but i don't know what
to do. Please help, tell me what i am doin wrong
here are the functions involved
int parse_line(const char* response)
{
regex expression("a");
cmatch what;
if(regex_match(response, what, expression))
{
cout << "MATCH\n";
}
else
{
cout << "NO MATCH\n";
}
return 0;
}
int get_info(string domain, char* pipe_file)
{
string line;
Message msg;
strstream command;
command << "/usr/bin/whois " << domain.c_str()
<< " > " << pipe_file;
system(command.str());
ifstream f(pipe_file);
while (!f.eof())
{
getline(f, line);
parse_line(line.c_str());
}
f.close();
return 0;
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=207586&aid=795936&group_id=7586
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Boost-bugs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/boost-bugs
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
