Re: [boost] Re: Compiler status for GCC 3.3

[Giovanni Bajo]

On Friday, July 04, 2003 12:38 AM [GMT+1=CET],
David Abrahams <[EMAIL PROTECTED]> wrote:

>> On the other hand if your native compiler is GCC and your system was
>> not configured with that setting, then you may get into trouble --
>> since you'll be mixing translation units with different ABIs.
>
> Furthermore, that sounds like a workaround.  Isn't it still a
> compiler bug that it doesn't work without -fabi-version=0?

No, it's correctly fixed, but since it's a fix that breaks ABI,  the version
number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI. If you want to
activate the new version, you have to explicitally say so. "-fabi-version=0"
always selects the last version of the ABI.

Giovanni Bajo


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Filtered stream-buffer, part 3

[Daryle Walker]

For the past few weeks, some posters were talking about streambufs that 
can decorate another stream buffer.  I wrote up a third version at 
.

The differences from the previous version is that is actually 
implements filtering for the main functions, the reading, un-reading, 
and writing methods.  These functions use the string and allocator 
stuff I started to put in the previous version.

BTW, the  header can be found in the 
Sandbox CVS.

One flaw I see currently is that _every_ character that has ever been 
(fully) read and/or putback is saved.  How should I set up the limits?

Daryle

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] New Iterator Adapters - filter_iterator

[David Abrahams]

Thomas Witt <[EMAIL PROTECTED]> writes:

> Dave,
>
> On Thursday 03 July 2003 09:32, David Abrahams wrote:
>> Thomas Witt <[EMAIL PROTECTED]> writes:
>> > I've checked in a fix for this. Static asserts make the instantiation of
>> > iterator_adaptors members fail depending on the iterator category. You
>> > may want to try it, though I don't have access to VC until tomorrow, so
>> > it is not guaranteed to work.
>>
>> I guess with the new categories that might be OK.  With the old
>> categories it was neccessary to allow operations which didn't
>> correspond to the category so that users could build, e.g., random
>> traversal readable rvalue iterators (had to be labeled as input
>> iterator).  We should take care that we're not disallowing people from
>> building useful iterators with capabilities that aren't accounted for
>> by our categories.
>
> The reason I choose to do it this way was that it was the least intrusive 
> modification that did the job. I can envision a more sophisticated mix-in 
> based approach but frankly I don't think that it's worth it.
>
> As you said the problem of disallowing usefull combinations was mostly due to 
> the old categories, but even with the old categories I would prefer the safe 
> road. The user who wants to provide more than the category asks for can 
> always reimplement the needed functions in a derived class. I like the idea 
> of being explicit about doing something special. Furthermore I think that 
> this inconvenience is more than outweighed by the added safety. Things that 
> accidently compile should be avoided whereever possible.

In that case, in addition to asserting statically, shouldn't we use
enable_if to "turn off" the top-level functions?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: New Iterator Adapters - filter_iterator

[David Abrahams]

Thomas Witt <[EMAIL PROTECTED]> writes:

> John,
>
> John R. Bandela wrote:
>> Should filter_iterator use iterator_facade as its base instead of
>> iterator_adapter? It seems the iterator_adapter is incorrectly implementing
>> advance.
>
> I wouldn't say that it is incorrectly implementing advance. AFAICS
> the problem is that there is no way to restrict the functionality
> that iterator_adaptor provides in a derived class. 

Sure there is; you can supply a non-compiling templated advance
operation if you want to disable it.

> I am not yet decided what the right fix to this issue is, maybe a
> mix in based implementation of iterator_adaptor is the right way to
> go.

Careful; I don't really have a clear picture of what you have in mind,
but that might make bloated iterators since few compilers implement
EBO under multiple-inheritance.

>> Regards,
>> John Bandela
>>
>> PS: I don't know if this is the place to ask, but I have updated
>> tokenizer to the new iterator adapters. Is there some place it
>> should be placed pending release of the new iterator_adapters?
>
> I was under the impression that Dave is gonna move it to the main
> trunk real soon, so keeping it on your local disk for a few more
> days might be the easiest solution. Dave?

I'm on vacation until the 6th at least.  Joel volunteered to make that
move, though I'm not sure what his schedule looks like.  If he's
bitten off more than he can chew I may jump in to help out.  Joel?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Compiler status for GCC 3.3

[David Abrahams]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> | I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond already
> | reported the issue, Paul also analyzed it here
> | http://groups.yahoo.com/group/ublas-dev/message/676
> | 
> | In essence: setting -fabi-version=0 should solve the problem.
>
> On the other hand if your native compiler is GCC and your system was
> not configured with that setting, then you may get into trouble --
> since you'll be mixing translation units with different ABIs.

Furthermore, that sounds like a workaround.  Isn't it still a
compiler bug that it doesn't work without -fabi-version=0?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: New Iterator Adapters - filter_iterator

[Joel de Guzman]

"David Abrahams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]

>> I was under the impression that Dave is gonna move it to
>> the main
>> trunk real soon, so keeping it on your local disk for a
>> few more
>> days might be the easiest solution. Dave?
>
> I'm on vacation until the 6th at least.  Joel volunteered
> to make that
> move, though I'm not sure what his schedule looks like.
> If he's
> bitten off more than he can chew I may jump in to help
> out.  Joel?

I'm cool. Let's do it.

--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: why is config not part of the public boost interface ?

[David Abrahams]

Ulrich Eckhardt <[EMAIL PROTECTED]> writes:

> Hi!
>
> I'm talking about http://boost.org/libs/config/config.htm. In 
> http://boost.org/libs/libraries.htm#workarounds it says 'not intended for 
> library users'. Why not ? 

I just don't think we want to be bothered to field support requests on
the config library from people at large.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[David Abrahams]

Markus Werle <[EMAIL PROTECTED]> writes:

>> Dear Boosters,
>> 
>> The enable_if library defines the enable_if and disable_if templates,
>> which are tools for controlling which function templates are included
>> in the overload resolution set based on the properties of the argument
>> types.
>> 
>> The following example demonstrates their use:
>> 
>> template 
>> typename enable_if::value, void>::type foo(T t) {
>>   std::cout << "An arithmetic type\n";
>> }
>> 
>> template 
>> typename disable_if::value, void>::type foo(T t) {
>>   std::cout << "Not an arithmetic type\n";
>> }
>
> Wow! C++ always has a solution for its own problems:
> I always wondered how I could prevent Daixtrose template operators 
> get applied to other user's or builtin types and decided to put 
>
> template  
> SomeComplicatedType operator+(T1 const &, T2 const &)
>
> et. al. into their own namespace DefaultOps.
>
> As of today Daixtrose users are explicitly forced to say
> using namespace Daixt::DefaultOps if they want their code to compile.
> And still may run into disambiguities when they include other beasts
> of that kind. This is annoying.

Yes, I've been meaning to apply the same fix to Boost.Python's "self"
operators ever since I learned about enable_if last fall.
Unfortunately, not all compilers support it so the special namespace
is still needed, but at least we can make things work perfectly on
some compilers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] New Iterator Adapters - filter_iterator

[Thomas Witt]

Dave,

On Thursday 03 July 2003 09:32, David Abrahams wrote:
> Thomas Witt <[EMAIL PROTECTED]> writes:
> > I've checked in a fix for this. Static asserts make the instantiation of
> > iterator_adaptors members fail depending on the iterator category. You
> > may want to try it, though I don't have access to VC until tomorrow, so
> > it is not guaranteed to work.
>
> I guess with the new categories that might be OK.  With the old
> categories it was neccessary to allow operations which didn't
> correspond to the category so that users could build, e.g., random
> traversal readable rvalue iterators (had to be labeled as input
> iterator).  We should take care that we're not disallowing people from
> building useful iterators with capabilities that aren't accounted for
> by our categories.

The reason I choose to do it this way was that it was the least intrusive 
modification that did the job. I can envision a more sophisticated mix-in 
based approach but frankly I don't think that it's worth it.

As you said the problem of disallowing usefull combinations was mostly due to 
the old categories, but even with the old categories I would prefer the safe 
road. The user who wants to provide more than the category asks for can 
always reimplement the needed functions in a derived class. I like the idea 
of being explicit about doing something special. Furthermore I think that 
this inconvenience is more than outweighed by the added safety. Things that 
accidently compile should be avoided whereever possible.

Thomas

-- 
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

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] New Iterator Adapters - filter_iterator

[David Abrahams]

Thomas Witt <[EMAIL PROTECTED]> writes:

> John,
>
> On Wednesday 02 July 2003 02:34, John R. Bandela wrote:
>> I was playing with the new iterator adapters in the sandbox. As I was
>> looking at filter_iterator, I found that it allows user code to increment
>> it like a random access iterator. Here is an example that compiled on VC
>> 7.1
>
> I've checked in a fix for this. Static asserts make the instantiation of 
> iterator_adaptors members fail depending on the iterator category. You may 
> want to try it, though I don't have access to VC until tomorrow, so it is not 
> guaranteed to work.

I guess with the new categories that might be OK.  With the old
categories it was neccessary to allow operations which didn't
correspond to the category so that users could build, e.g., random
traversal readable rvalue iterators (had to be labeled as input
iterator).  We should take care that we're not disallowing people from
building useful iterators with capabilities that aren't accounted for
by our categories.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Boost::thread feature request: thread priority

[Maxim Egorushkin]

"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

> http://google.com/groups?selm=3f01e07b%40usenet01.boi.hp.com
> (Subject: Re: Does anyone think 'volatile' is a platform-independent
>  way to make variable access thread safe?)
>
> Check out this entire thread. Follow the links. ;-)

Thank you, Alexander, for the links. Seems like the issue is undefined
behaviour when casting away volatile. Do I get it right?



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] why no strict ownership smart pointer in boost

[Howard Hinnant]

On Thursday, July 3, 2003, at 11:05  AM, Schoenborn, Oliver wrote:

I could sure use some feedback about how the technique stands to 
generic
algorithms.
I'm not sure how this will work with your library, but the below 
example is meant to illustrate the kind of accidental ownership 
transfer I am concerned about.  With your statement:

No, transient shared ownership.
I suspect that everything will be just fine.

my_partition3 is meant to be a "typical" 3rd party generic algorithm 
taking a range of iterators, and a generic compare functor.  It looks 
at the first, middle and last elements in the range, selects the median 
of those elements, and then partitions the range using the afore 
selected median.

#include 
#include 
template 
It
my_partition3(It first, It last, Comp comp)
{
	typedef typename std::iterator_traits::difference_type 
difference_type;
	typedef typename std::iterator_traits::value_type  value_type;
	difference_type len = std::distance(first, last);
	switch (len)
	{
	case 0:
	case 1:
		return first;
	case 2:
		--last;
		if (comp(*last, *first))
			std::iter_swap(first, last);
		return last;
	}
	It middle = first;
	std::advance(middle, len/2);
	--last;
	if (comp(*middle, *first))
		std::iter_swap(first, middle);
	if (comp(*last, *first))
	{
		std::iter_swap(first, last);
		std::iter_swap(middle, last);
	}
	else if (comp(*last, *middle))
		std::iter_swap(middle, last);
	++last;
	value_type partition = *middle;
	while (true)
	{
		while (true)
		{
			if (first == last)
return first;
			if (!comp(*first, partition))
break;
			++first;
		}
		--last;
		while (true)
		{
			if (first == last)
return first;
			if (comp(*last, partition))
break;
			--last;
		}
		std::iter_swap(first, last);
		++first;
	}
}

The "catch" in this otherwise reasonable example is the statement:

	value_type partition = *middle;

This statement assumes copy semantics.  That is, *middle is assumed to 
be left unchanged.  If you create a range of shared_ptr, with an 
indirect less-than comparator for example, then things work just great:

#include 
#include 
struct indirect_less
{
template 
bool operator()(const T& x, const T& y) const
{ return *x < *y; }
};
int main()
{
typedef std::tr1::shared_ptr Ptr;
Ptr ia[9];
Ptr* begin = ia;
unsigned size = sizeof(ia)/sizeof(ia[0]);
Ptr* end = ia + size;
for (unsigned k = 0; k < size; ++k)
ia[k].reset(new int(k));
std::random_shuffle(begin, end);
for (Ptr* k = begin; k < end; ++k)
std::cout << **k << ' ';
std::cout << '\n';
Ptr* i = my_partition3(begin, end, indirect_less());
for (Ptr* k = begin; k < i; ++k)
std::cout << **k << ' ';
std::cout << "- ";
for (Ptr* k = i; k < end; ++k)
std::cout << **k << ' ';
}
But if you:

	typedef std::auto_ptr Ptr;

instead, then you get trouble.  It compiles, but the "partition 
assignment" now transfers ownership out of the container.  This results 
in a runtime crash.

It is examples such as this one, that have made me come to believe:

	It is not safe to move with copy syntax from lvalues.

I.e. publicly accessible "copy" constructors that look like A(A&) are 
accidents waiting to happen.

It sounds to me like this isn't a problem with the NoPtr lib, even when 
vector is used in place of a raw array in the above example.  
Either it will compile and work, or won't compile (both of which I 
consider acceptable behavior).  It is compiling and not working that I 
dislike so much.

-Howard

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] why is config not part of the public boost interface ?

[Beman Dawes]

At 08:07 AM 7/3/2003, Ulrich Eckhardt wrote:
>Hi!
>
>I'm talking about http://boost.org/libs/config/config.htm. In
>http://boost.org/libs/libraries.htm#workarounds it says 'not intended for 

>library users'. Why not ?

The Boost config system primarily addresses issues that are affecting Boost 
code. So it would be a bit presumptuous to try to pass it off as a general 
use tool.

On the other hand, the config system is really useful if you are faced with 
porting to many platforms. It has been in use for quite a while now. So 
maybe we should soften the wording you quote a bit.

--Beman

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] why no strict ownership smart pointer in boost

[Schoenborn, Oliver]

> Are you transferring ownership (moving) with copy syntax 
> within the containers in order to satisfy the container's copyable 
> requirement?  

No, transient shared ownership.

> If so, is there not a danger that ownership will get 
> accidently transferred out of the container, especially if that 
> container is used with some generic algorithm?  

>From a syntactic POV, no:
DynObj obj(new T);
std::list< DynObj::InValueContainer > list;
list.push_back(obj.giveAway());
DynObj dynobj = list.front(); //compile error

> And if the container 
> itself is copied, which copy owns the pointers?

No way to currently guard against this, except that an assertion will fail
at first attempt to use anything in either of the two containers. 

I could sure use some feedback about how the technique stands to generic
algorithms. 

Oliver
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[Jaakko Jarvi]

In our last exciting episode Markus Werle wrote:

> With enable_if this can be reduced to say it once and for all times:
> Users just have to specialize a traits class

> template  struct DaixtroseTraits
> {
>   enum { use_default_ops = false };
> };

> and I change my operators to

> template  enable_if
> <
>  (
>   (DaixtroseTraits::use_default_ops == true)
>   &&
>   (DaixtroseTraits::use_default_ops == true)
>   ),
>   SomeComplicatedType 
> >::type
> operator+(T1 const &, T2 const &);

> and move them from namespace Daixtrose::Defaultops to namespace Daixtrose.
> What do You think? Did I miss any side effects?

I don't think you missed anything. That's the way it works, and it is
what we've been using in an ET-capable library for a while. 

  Cheers, Jaakko

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [thread] bugfix + possible deadlock

[Pavel Vozenilek]

Boost 1.30, Windows.

libs/thread/src/once.cpp, function call_once(), CreateMutex() should be
replaced with CreateMutexA() in one place.


Looking into the code, I have question: if the 'called once' function
throws, it leaves (under Win32) opened mutex and this can deadlock the app
(if there are more functions to be 'called once').

The mutex can be closed even in this case and function flagged as executed.


/Pavel




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] why is config not part of the public boost interface ?

[Ulrich Eckhardt]

Hi!

I'm talking about http://boost.org/libs/config/config.htm. In 
http://boost.org/libs/libraries.htm#workarounds it says 'not intended for 
library users'. Why not ? 

I just stumbled across this some time ago and was very surprised because I use 
exactly that in quite some code that doesn't otherwise use any 'real code' 
from boost...

Ulrich Eckhardt

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Review request: enable_if

[Markus Werle]

Jaakko Jarvi wrote:

> Dear Boosters,
> 
> The enable_if library defines the enable_if and disable_if templates,
> which are tools for controlling which function templates are included
> in the overload resolution set based on the properties of the argument
> types.
> 
> The following example demonstrates their use:
> 
> template 
> typename enable_if::value, void>::type foo(T t) {
>   std::cout << "An arithmetic type\n";
> }
> 
> template 
> typename disable_if::value, void>::type foo(T t) {
>   std::cout << "Not an arithmetic type\n";
> }

Wow! C++ always has a solution for its own problems:
I always wondered how I could prevent Daixtrose template operators 
get applied to other user's or builtin types and decided to put 

template  
SomeComplicatedType operator+(T1 const &, T2 const &)

et. al. into their own namespace DefaultOps.

As of today Daixtrose users are explicitly forced to say
using namespace Daixt::DefaultOps if they want their code to compile.
And still may run into disambiguities when they include other beasts
of that kind. This is annoying.

With enable_if this can be reduced to say it once and for all times:
Users just have to specialize a traits class

template  struct DaixtroseTraits
{
  enum { use_default_ops = false };
};

and I change my operators to

template  
enable_if
<
 (
  (DaixtroseTraits::use_default_ops == true)
  &&
  (DaixtroseTraits::use_default_ops == true)
  ),
  SomeComplicatedType 
>::type
operator+(T1 const &, T2 const &);

and move them from namespace Daixtrose::Defaultops to namespace Daixtrose.
What do You think? Did I miss any side effects?

Thank You, Jaakko!


Markus


-- 

Build your own Expression Template Library with Daixtrose!
Visit http://daixtrose.sourceforge.net/ (the sandbox for boost::etl?)



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Interest in multiindex_set? (again)

[Joaquín Mª López Muñoz]

Arkadiy Vertleyb ha escrito:

[...]

>
> The reason we are interested in the multiindex_set is that we want to
> provide a more efficient implementation for our table, that is currently
> implemented with std::vector, although Ed Brey already suggested an
> alternative with std::set(that we need to examine).
>
> Regards,
>
> Arkadiy
>

I suggest you download multiindex.zip from the files section and play
with it to see if it fits your needs. If you need assistance with the usage of
the library don't hesitate to contact me. Next week some sort of preliminary
documentation  should be prepared, anyway.

Regards,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost