Re: generating unique ordinal value at compile time

> values. What I want is something like this:
> 
> struct system1 : ordinal<get_next_system_ordinal()> { };
> struct system2 : ordinal<get_next_system_ordinal()> { };
> 
> where I don't really care what the specific order is, just that the
> ordinal values are unique... Anyone have a bright idea on how to
> accomplish this? Preprocessor?

Hmm, I doubt you can do this with as much generality as you would like,
especially since it would be hard to ensure uniqueness across multiple
translation units.

What about a solution like this:

/////////////

struct ordinal_tag {};

template<class A>
struct ordinal	{
	static ordinal_tag const tag;
	template<class B>
	bool operator<(ordinal<B> const& other)	{
		return &tag < &other.tag;
	}
};

template<class A>
ordinal_tag const ordinal<A>::tag = ordinal_tag();

Re: generating unique ordinal value at compile time

On 2/28/07, Lewis Hyatt <lhyatt <at> princeton.edu> wrote:
> Now that I think about it, don't people use std::map<void*,T> all the time? How
> do they make sure that is portable?
>
std::less for pointers gives you a total order.  20.3.3.8. (Draft
standard link: http://www.open-std.org/jtc1/sc22/open/n2356/lib-utilities.html
)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: generating unique ordinal value at compile time

On 3/1/07, Lewis Hyatt <lhyatt <at> princeton.edu> wrote:
> > values. What I want is something like this:
> >
> > struct system1 : ordinal<get_next_system_ordinal()> { };
> > struct system2 : ordinal<get_next_system_ordinal()> { };
> >
> > where I don't really care what the specific order is, just that the
> > ordinal values are unique... Anyone have a bright idea on how to
> > accomplish this? Preprocessor?
>
> Hmm, I doubt you can do this with as much generality as you would like,
> especially since it would be hard to ensure uniqueness across multiple
> translation units.
>
> What about a solution like this:
>
> /////////////
>
> struct ordinal_tag {};
>
> template<class A>
> struct ordinal  {
>         static ordinal_tag const tag;
>         template<class B>
>         bool operator<(ordinal<B> const& other) {
>                 return &tag < &other.tag;
>         }
> };
>
> template<class A>

Re: generating unique ordinal value at compile time

Giovanni Piero Deretta <gpderetta <at> gmail.com> writes:

> > template<class A>
> > ordinal_tag const ordinal<A>::tag = ordinal_tag();
> >

> You need to actually define const static members of out of class.

That's what the above line does. It would work fine.

> Comparing pointers outside of arrays is not portable, on the other
> hand std::less<T*> is required to do the RightThing.

That is good to know, thanks!

> Anyways, while pointers to static function variables are guaranteed
> unique, they are not  constant expressions, so this might not be what
> the OP was looking for.

Pointers to class static members can be passed as template non-type arguments,
though, which might be sufficient.

-Lewis

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

Re: [1.34.0] Re: [iostreams] patch for wide_streams.hpp forHP-UX

Boris Gubenko wrote:
> Thomas Witt wrote:
>> Looks good to me. Come to think of it, Boris do you have CVS write
>> access?
> 
> No, I don't, but, I, probably, should, so, getting the write
> permission will be appreciated.
> 
> In any case, even if granted write access to CVS, as a newcomer,
> I'd be reluctant to make any changes to the rc branch at this point
> in the development cycle.

I agree with Jeff on this one. OK to commit messages are probably 
sufficient.

Thanks

Thomas

--

-- 
Thomas Witt
witt <at> acm.org

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

[python] Fix for boost::python::import

The attached patch fixes the boost::python::import implementation.
It used to work fine for modules already ('physically') imported
into the process, but not for new ones.

I'd like to apply to HEAD, and would like to ask whether it is OK
for the R_1_34 branch, too.

The problem is that the 'import' function is new (well, it's
actually two years old, but not in any official release), and
no unit test exists. Thus, part of this patch is a unit test
that demonstrates the failure on the existing implementation,
as well as the fix.

OK to commit to HEAD and R_1_34 ?

Thanks,
		Stefan

--

-- 

      ...ich hab' noch einen Koffer in Berlin...

Index: libs/python/src/import.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/src/import.cpp,v
retrieving revision 1.2
diff -u -r1.2 import.cpp
--- libs/python/src/import.cpp	27 Oct 2006 21:17:25 -0000	1.2
+++ libs/python/src/import.cpp	1 Mar 2007 02:00:47 -0000

Re: Shared pointers and pointers to members issue (with fix)

Michael Anderson wrote:
> Howdy everyone.
> I have some code that uses pointers to member variables that I want to 
> switch to using boost::shared_ptrs, some of the code looks like this.
> 
> class Bar {};
> class Foo
> {
>  public:
>     Bar bar;
> };
> 
> ...
> Foo * fooptr = new Foo;
> Bar * barptr = &Foo.bar;
> ...
> 
> So to make this work with shared_ptrs I can do this:
> 
> class Bar {}
> class Foo
> {
>   public:
>    Foo() : bar(new Bar) {}
>    shared_ptr<Bar> bar;
> };
> 
> ...
> <snip>
> 

Re: [regex] patches for Tru64 and HP-UX

John Maddock wrote:
> Can you test the attached patch then?  If you can assure me that the RW
> version check is correct (presumably you will up the version number if the
> issue gets fixed?), and that it has no unfortunate effects on the other
> Boost regression tests [...]

Unfortunately, the patch broke some tests, in particular, 9 tr1 library
tests. This is because roguewave.hpp #include's <iterator>. Just
inclusion of <iterator> makes the tests fail. I did not analyze the
failures, I guess, the tests don't expect <iterator> to be included.

I think, we have 3 options:

1) put your fix in some regex library header which includes <iterator>
   anyway.

2) put my original fix which does not require any headers in roguewave.hpp

3) do nothing: mark tests affected by this RW bug expected failures and
   wait for the compiler kit with the fix (for the reference, this RW bug
   is tracked internally as CR JAGag33243).

I'm running the tests with 2) now, to verify that it indeed is a viable
solution.

Thanks,
  Boris

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

stack-based std::containers

I have functions like say a quartic equation solver that can return a 
variable number of solutions.  It would be clean IMO to return or pass 
by reference a std::vector or like container that store the solutions. 
However heap allocation is fairly expensive here so the usual solution 
is to have a local array with max solutions elements and pass that by 
reference into the solver and return the number of solutions.  This is 
ugly to use and read.  Is there a library for stack-based std-like 
containers?  Alternatively is it possible to make an compatible 
stack-based allocator for std::vector using alloca?

Thanks,

Michael Marcin

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

Re: stack-based std::containers

Michael Marcin wrote:
> I have functions like say a quartic equation solver that can return a 
> variable number of solutions.  It would be clean IMO to return or pass 
> by reference a std::vector or like container that store the solutions. 
> However heap allocation is fairly expensive here so the usual solution 
> is to have a local array with max solutions elements and pass that by 
> reference into the solver and return the number of solutions.  This is 
> ugly to use and read.  Is there a library for stack-based std-like 
> containers?  Alternatively is it possible to make an compatible 
> stack-based allocator for std::vector using alloca?

You can definitely make a stack-based version of allocators. The 
allocator would store a  pointer to the local array.
It's still fairly ugly though.

I suggest that you could look at STLSoft's auto_buffer:

http://synesis.com.au/software/stlsoft/help/classstlsoft_1_1auto__buffer.html

I suggested the construction of a similar class in boost for SoC last year.

-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost