Boost :

jamescurran_at_[hidden]

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson
________________________________________________________________________
________________________________________________________________________
Message: 6
   Date: Mon, 19 Nov 2001 22:26:05 -0500
   From: "David Abrahams" <david.abrahams_at_[hidden]>
Subject: Re: Re: A couple of issues in submitting typelists to boost
And why do you want this to be a macro?
----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 19, 2001 9:53 PM
Subject: Re: [boost] Re: A couple of issues in submitting typelists to
boost
> > > #define SUPERSUBCLASS(T, U) \
> > >     (::Loki::Conversion<const U*, const T*>::exists && \
> > >     !::Loki::Conversion<const T*, const void*>::sameType)
> > >
> >
> > Why don't to implement this using boost::is_convertable and
> > boost::same_type?
>
> I just pasted code from Loki. My entire point was to suggest adding a
> similar macro to boost.
>
>
> Andrei
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
________________________________________________________________________
________________________________________________________________________
Message: 7
   Date: Tue, 20 Nov 2001 04:33:29 -0000
   From: dylan_at_[hidden]
Subject: Re: arguments parsing, wildcard matcher
--- In boost_at_y..., dylan_at_m... wrote:
> --- In boost_at_y..., "Henrik Ravn" <henrik_at_r...> wrote:
> > > > struct file_finder
> > > > {
> > > > 	file_finder(const char* pattern);
> > > > 	~file_finder();
> > > > 	typedef const char* const* iterator;
> > > > 	operator bool() const;
> > > > 	iterator begin();
> > > > 	iterator end();
> > > > private:
> > > > 	glob_t glob_;
> > > > };
> > > > 
> > > 
> > 
I've uploaded file_finder.zip containing file_finder.hpp (which 
declares and implements the entire class), and for win32, glob.h and 
glob.c - I'm not sure what the policy on providing platform specific 
headers and source files is, so I just left them in a 'win32' 
directory.  On POSIX platforms they aren't needed of course.  
Obviously you can also use something like cygwin if you are happy 
with that dependency.
Dylan
________________________________________________________________________
________________________________________________________________________
Message: 8
   Date: Tue, 20 Nov 2001 00:27:39 -0500
   From: "David Abrahams" <david.abrahams_at_[hidden]>
Subject: type_traits request
I just came across a repeated need for add_cv<T>. We already have
remove_cv<T>. How about it, for symmetry?
-Dave
===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html
        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================
________________________________________________________________________
________________________________________________________________________
Message: 9
   Date: Mon, 19 Nov 2001 22:19:06 -0800
   From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Subject: Re: type_traits request
> I just came across a repeated need for add_cv<T>. We already have
> remove_cv<T>. How about it, for symmetry?
I guess that would be too simple: add_cv<T> is just "const volatile T".
Andrei
________________________________________________________________________
________________________________________________________________________
Message: 10
   Date: Mon, 19 Nov 2001 22:20:24 -0800
   From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Subject: Re: Re: A couple of issues in submitting typelists to boost
> And why do you want this to be a macro?
I believe that SUPERSUBCLASS is an important, useful abstraction.
Writing
the content of SUPERSUBCLASS inline in code just hides the intent with
the
mechanics.
Andrei
________________________________________________________________________
________________________________________________________________________
Message: 11
   Date: Tue, 20 Nov 2001 19:34:04 +1300
   From: Ross Smith <r-smith_at_[hidden]>
Subject: Re: Re: A couple of issues in submitting typelists to boost
Andrei Alexandrescu wrote:
> 
> > And why do you want this to be a macro?
> 
> I believe that SUPERSUBCLASS is an important, useful abstraction.
Writing
> the content of SUPERSUBCLASS inline in code just hides the intent with
the
> mechanics.
Yes, but WHY A MACRO?
Much as I admire your code in general, Andrei, you do have this
deplorable tendency to fall in love with the preprocessor. :-) There are
several concepts in MC++D (TYPELIST<n> is another) that, for no good
reason that I can see, you've gratuitously written as macros when they
could be expressed just as easily in safe code.
-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith_at_[hidden] ........................ http;//halflife.mani.ac.nz/
        "A wise man learns from the mistakes of others; a fool
        learns only from his own."     -- Gen. Aleksandr Lebed
________________________________________________________________________
________________________________________________________________________
Message: 12
   Date: Tue, 20 Nov 2001 06:38:24 -0000
   From: dylan_at_[hidden]
Subject: huge container types?
Hi,
Has anyone tried implementing something to support huge containers 
that couldn't possibly fit into memory (even using swap space). I'm 
not talking about sparse arrays, I mean where you actually need 8Gig 
of space to store information that you are working on actively, and 
need to be able to access it transparently without caring whether it 
is stored on disk or in memory (so that, for instance, you can 
dynamically adjust how much is stored in memory and how much on disk).
8 gig is just about enough to hold the matrices necessary to do 
certain forms of boundary element and finite element analysis on 
complex input models, so this is not a purely theoretical need!
I tried to think about what would be involved in implementating, say, 
std::vector so that you could specify that a certain amount would be 
cached in memory, while the rest was manually read and written to 
disk.  One implication is that operations that reduce the size of the 
vector (including destruction) would be potentially extremely slow as 
all the elements being destructed would have to be "swapped" in first.
An option to disable this would probably be necessary (user beware of 
course).
Ideally of course it should be possible by implementing just an 
custom allocator.  Assuming that a vector's iterator ultimately uses 
allocator::pointer then if you write an allocator where pointer is 
actually a 'smart pointer' that swaps as needed, this would probably 
be 90% of the work.
Well actually "ideally" the OS would handle all this for you, but the 
reality is that very few OS's are set up to optimally use all 
available disk space for swapping.  Even most unices don't seem to 
handle trying to configure more than 4 gig of swap space too well, 
and NT is doing well if it handles 4 meg...
Anyway size_t is usually a 32-bit int on 32-bit systems which severly 
limits how much memory new[] can handle - I'm making the assumption 
that size_type will be 64-bit.
Thoughts/comments...
Dylan
________________________________________________________________________
________________________________________________________________________
Message: 13
   Date: Tue, 20 Nov 2001 06:56:19 -0000
   From: "Gennadiy E. Rozental" <rogeeff_at_[hidden]>
Subject: Re: arguments parsing, wildcard matcher
--- In boost_at_y..., "David A. Greene" <greened_at_e...> wrote:
> >   For example to register an action for particular argument 
presence 
> > you will need somethink like:
> >      new argument( ..., do_this_action_if_present() );
> > While the same logic could be implemented like this:
> >    if( argument.is_present() )
> >      do_somethink();
> > 
> > The second version is also more stable because you now know in 
which 
> > order events will ocure.
> 
> 
> Hmm...I prefer the first because things are logically separated
> (defining what the option keywords are and defining what they do).
I lost me there. I think vice versa. First version unite 2 think 
while second separate argument identification and parsing from 
argument processing.
> 
> We often want to do a lot more than just know if a switch
> has been set.  I can imagine situations where the meanings of
> switches changes based on what other arguments are present.
> There is an ordering issue, yes.  The processing order is defined
> by which order the arguments appear on the command line.  Perhaps
> not ideal but some other convention could be defined.
IMHO you will immediately find a bag of problems as soon as start 
mixing 2 things in one bottle. The design should encorage users to 
separate actions. Was the action performd while parsing a command 
line? What to do if user put arguments in wrong order? Or framework 
that smart that it will be able to handle any input? We should not 
make a very smart (and very complex appropriately) components by 
itself. If it possible we could try to place a hook for extentions. 
And everybody could make parser as smart as thay need.
Regards,
Gennadiy.
> 
> I'm brainstorming here, not presenting the One True Way.
> 
>                               -Dave
> 
> -- 
> 
> "Some little people have music in them, but Fats, he was all music,
>   and you know how big he was."  --  James P. Johnson
________________________________________________________________________
________________________________________________________________________
Message: 14
   Date: Tue, 20 Nov 2001 02:07:41 -0500
   From: "Michael D. Crawford" <crawford_at_[hidden]>
Subject: huge container types?
While it was not C++, I once implemented a scrolling list GUI object on
the Mac 
OS in ANSI C that had hundreds of thousands of items for tens of
megabytes of 
list data.  This was in the days when 32 MB of RAM was a lot, and
virtual memory 
was not always used on the Mac OS and didn't perform all that well.
The native Mac OS List Manager was limited to 32kb of data because it
used 
signed 16 bit offsets into your data.  The usual way to get more data
into the 
list was to scroll a list of pointers, which would then get you 8192
items, 
still not nearly enough for my case.
The application was text retrieval off a CDROM.  I forget what exactly
went in 
the list, but the CD was called The Total Heart and in general had a lot
of SGML 
text about heart medicine, anatomy and health.
What I did was write a lookalike replacement for the list manager that
held at 
most a couple hundred items in memory.  Whenever you would scroll one
way or 
another in the list, it would grab some records off the CD ahead of
where you'd 
scrolled (or behind if you were scrolling backwards), and dump some off
its list 
if the cache was more than I'd configured it to be.
If you made a large jump I just dropped the cache and fetched new
records.  If 
one were to do it in a fancier way, you could keep discontinuous cache
ranges so 
if you jump back and forth then you could have immediate access.
What you'd want to do is implement something like a Least Recently Used
cache 
algorithm that worked like whichever of the existing STL containers fits
your 
application most naturally.  Dereferencing an iterator will also move
your cache 
entry to the front of the list.  Or alternatively you could  use a Least
Frequently Used cache algorithm in which derefencing an iterator will
increment 
an access count.
In any case, make a parameter to the constructor that gives the cache
size.  Or 
for extra credit make sure you're exception-safe and just drop cache
items when 
you run out of memory.
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
crawford_at_[hidden]
   Tilting at Windmills for a Better Tomorrow.
     "I give you this one rule of conduct. Do what you will, but speak
      out always. Be shunned, be hated, be ridiculed, be scared,
      be in doubt, but don't be gagged."
      -- John J. Chapman, "Make a Bonfire of Your Reputations"
         http://www.goingware.com/reputation/
________________________________________________________________________
________________________________________________________________________
Message: 15
   Date: Mon, 19 Nov 2001 23:04:55 -0800
   From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Subject: Re: Re: A couple of issues in submitting typelists to boost
> Yes, but WHY A MACRO?
Ok, I agree in this case one can use super_subclass<T, U>::type (can you
say
"pretty ugly")...
> Much as I admire your code in general, Andrei, you do have this
> deplorable tendency to fall in love with the preprocessor. :-) There
are
> several concepts in MC++D (TYPELIST<n> is another) that, for no good
> reason that I can see, you've gratuitously written as macros when they
> could be expressed just as easily in safe code.
You must be referring to the TYPELIST_nn macros.
It's very simple. I don't give a rat's ass on the preprocessor and I'm
fully
aware of its vandalism. It's just that the set of requirements that I
had
for typelist "constructors" left the preprocessor as the only contender:
1. easy to use
2. scaleable up to more parameters
(We can discuss separately whether or not these were good criteria.)
So I put together the nasty TYPELIST_1 to TYPELIST_50 and used them. I
didn't notice name clashes etc., but I did notice an important
shortcoming:
3. If you use a comma inside a macro, it won't work. Consider:
typedef TYPELIST_2(vector<int, myallocator>, vector<int, yourallocator>)
    TwoVectors;
that won't work because the preprocessor strongly believes that you
actually
passed four arguments to TYPELIST_2. What a nuisance. You can fix that
by
putting in place typedefs for those types.
So it's a tradeoff issue. Any solution that fixes point 3 fails on point
1,
point 2, or (most often) both 1 and 2.
Andrei
________________________________________________________________________
________________________________________________________________________
Message: 16
   Date: Tue, 20 Nov 2001 02:09:23 -0600
   From: "Corwin Joy" <cjoy_at_[hidden]>
Subject: Proposal: Sorted Vector Container
Michael Gradman and myself have uploaded a new contaier to the
boost files area in a folder called vec_multiset.
What it is:
A wrapper that holds a sorted vector in such a way as to make it look
like a std::multiset.
Why:
It has been observed by Scott Meyers ("Effective STL") and others that
in
many situations
when dealing with sorted data one has a "setup" phase followed by a
"lookup" phase where items are retrieved from the container.  In this
situation
a sorted vector can offer superior performance to the standard tree
implementation
used by multiset both in terms of memory and speed.  We have taken the
step
of wrapping a sorted vector with an interface very similar to a
std::multiset
to make it easy to convert code that uses multiset to a faster
implementation
when a setup/lookup pattern is followed.
How:
By using some fancy footwork we were able to preserve multiset
requirements
like iterator invariants after insertions/deletions and several other
features
making for quite a nice container.  There are really only two major
limitations
on this container versus a true multiset:
1. Because it uses a vector as the underlying container to hold data,
individual
elements may get shifted around in memory.  If you need pointer or
reference
validity throughout the lifetime of the container, use std::multiset.
Vec_multiset's
underlying container can shift the data elements around in memory.
However,
if you write your code in a more modern fashion to use iterators rather
than
pointers, you can still use vec_multiset.
2. Exception safety.  Because it uses vector to hold the data elements
this
container
suffers from the same exception safety issues a std::vector.
More documentation about how we built this container to preserve
interator
invariants
and other details can be found at:
Documentation:
http://groups.yahoo.com/group/boost/files/vec_multiset/vec_multiset.htm
Code:
http://groups.yahoo.com/group/boost/files/vec_multiset/vec_multiset.zip
________________________________________________________________________
________________________________________________________________________
Message: 17
   Date: Tue, 20 Nov 2001 00:09:40 -0800
   From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Subject: select_type.hpp
I think if_true in select_type ought to become a first-class citizen.
It's
useful enough to everyone.
I also suggest including the friendlier version:
    template <bool flag, typename T, typename U>
    struct select
    {
        typedef T type;
    };
    template <typename T, typename U>
    struct Select<false, T, U>
    {
        typedef U type;
    };
for compilers that support partial specialization. The if_true is
compiler-friendlier but considerably harder to use (that "template" in
the
middle of it is really annoying).
Andrei
________________________________________________________________________
________________________________________________________________________
Message: 18
   Date: Tue, 20 Nov 2001 08:14:23 -0000
   From: "Corwin Joy" <cjoy_at_[hidden]>
Subject: Re: Proposal: Sorted Vector Container
--- In boost_at_y..., "Corwin Joy" <cjoy_at_h...> wrote:
> Michael Gradman and myself have uploaded a new contaier to the
> boost files area in a folder called vec_multiset.
> 
One more comment.  So far, we have tested this with Visual C++ 6.0 
and GCC 2.96.
________________________________________________________________________
________________________________________________________________________
Message: 19
   Date: Tue, 20 Nov 2001 00:23:46 -0800
   From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
Subject: Quick q on simple type manipulation helpers
Are there somewhere in boost equivalents for the templates below?
    template <int v>
    struct int2type
    {
        enum { value = v };
    };
    
    template <typename T>
    struct type2type
    {
        typedef T original_type;
    };
Thanks,
Andrei
________________________________________________________________________
________________________________________________________________________
Message: 20
   Date: Tue, 20 Nov 2001 11:45:56 +0300
   From: Petr Ovchenkov <ptr_at_[hidden]>
Subject: Re: arguments parsing, wildcard matcher
Hmm, while you mixed walk through catalog and argument parsing?
IMO it a different tasks.
  - ptr
________________________________________________________________________
________________________________________________________________________
Message: 21
   Date: Tue, 20 Nov 2001 09:55:22 +0100
   From: Peter Schmitteckert (boost) <boost_at_[hidden]>
Subject: Re: can't get ublas files (Re: Re: Boost Matrix classes /
MTLv3)
Hello,
On Tuesday 20 November 2001 00:39, David Abrahams wrote:
> Try:
>
>   cvs -z3
-d:pserver:anonymous_at_[hidden]:/cvsroot/boost
>        co -rmatrix_development boost/libs/numeric/ublas
>
> or, since you already have got the module structure:
>
>     cvs -z3 update -rmatrix_development
Thanks for your hints, I tried both, removed my files I tried it again.
But I still can't find the sources. The test- and benchmarks- files 
are downloaded, but not the ublas sources.
Any help ?
best wishes
Peter
------------------
P.S.: 
peter_at_wawa:~/Boost/boost/libs/numeric/ublas$ ls *
CVS:
Entries  Repository  Root  Tag
bench1:
CVS  bench1.cpp  bench1.h  bench11.cpp  bench12.cpp  bench13.cpp
bench2:
CVS  bench2.cpp  bench2.h  bench21.cpp  bench22.cpp  bench23.cpp
bench3:
CVS  bench3.cpp  bench3.h  bench31.cpp  bench32.cpp  bench33.cpp
doc:
CVS             iterator.htm   matrix_sp.htm   vector.htm
container.htm   matrix.htm     proxy.htm       vector_et.htm
expression.htm  matrix_et.htm  storage.htm     vector_pr.htm
index.htm       matrix_pr.htm  storage_sp.htm  vector_sp.htm
test1:
CVS  test1.cpp  test1.h  test11.cpp  test12.cpp  test13.cpp
test2:
CVS  test2.cpp  test2.h  test21.cpp  test22.cpp  test23.cpp
test3:
CVS  test3.cpp  test3.h  test31.cpp  test32.cpp  test33.cpp
test4:
CVS  test4.cpp  test4.h  test41.cpp  test42.cpp  test43.cpp
test5:
CVS  test5.cpp  test5.h  test51.cpp  test52.cpp  test53.cpp
test6:
CVS  test6.cpp  test6.h  test61.cpp  test62.cpp  test63.cpp
peter_at_wawa:~/Boost/boost/libs/numeric/ublas$ cvs --version
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, 
                        Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public
License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS
________________________________________________________________________
________________________________________________________________________
Message: 22
   Date: Tue, 20 Nov 2001 10:22:27 +0100
   From: Toon Knapen <toon.knapen_at_[hidden]>
Subject: Re: can't get ublas files (Re: Re: Boost Matrix classes /
MTLv3)
Peter Schmitteckert (boost) wrote:
> Hello,
> 
> On Tuesday 20 November 2001 00:39, David Abrahams wrote:
> 
>>Try:
>>
>>  cvs -z3
-d:pserver:anonymous_at_[hidden]:/cvsroot/boost
>>       co -rmatrix_development boost/libs/numeric/ublas
>>
>>or, since you already have got the module structure:
>>
>>    cvs -z3 update -rmatrix_development
>>
> 
> Thanks for your hints, I tried both, removed my files I tried it
again.
> But I still can't find the sources. The test- and benchmarks- files 
> are downloaded, but not the ublas sources.
> 
> Any help ?
It's best you just checkout the whole matrix_development branch !
So remove your current attempt (to get rid of sticky tags) or make
a new directory, `cd` to this directory and do :
`cvs -z3 co -r matrix_development boost`
of course, your CVSROOT env. var should be defined or you have to use
the -d option of the CVS command.
This command will create the sources of uBlas in the libs subdirectory 
and the
headers in the boost/numeric/ublas directory.
let me know if you succeed
toon
________________________________________________________________________
________________________________________________________________________
Message: 23
   Date: Tue, 20 Nov 2001 05:15:30 -0500
   From: "David Abrahams" <david.abrahams_at_[hidden]>
Subject: Re: type_traits request
That's a good point. I remember we went through this about add_const<>
and
add_volatile<>, which made it in to the library ;-)
----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> > I just came across a repeated need for add_cv<T>. We already have
> > remove_cv<T>. How about it, for symmetry?
>
> I guess that would be too simple: add_cv<T> is just "const volatile
T".
>
>
> Andrei
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
________________________________________________________________________
________________________________________________________________________
Message: 24
   Date: Tue, 20 Nov 2001 05:36:50 -0500
   From: "David Abrahams" <david.abrahams_at_[hidden]>
Subject: Re: Re: Proposal: Sorted Vector Container
I'm really glad that someone is taking an active interest in this
subject
again!
Please have a look at
http://groups.yahoo.com/group/boost/message/3226
http://groups.yahoo.com/group/boost/message/3777
http://groups.yahoo.com/group/boost/files/associative_vector/
Without having looked at your code, I'll surmise that iterator stability
is
acheived by embedding a reference to the vector and an offset in the
iterator. I am not convinced that iterator stability is usually worth
the
cost, and I'd rather not pay for it if I wasn't going to use it. My plan
for
implementing stability was to provide pointer/reference stability via an
indirect_container adaptor which uses boost::indirect_iterator (In fact,
this is the work that spawned the Boost Iterator Adaptors Library). This
approach has several advantages, not least that reallocating the vector
becomes very cheap because it just has to copy POD data.
-Dave
----- Original Message -----
From: "Corwin Joy" <cjoy_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, November 20, 2001 3:14 AM
Subject: [boost] Re: Proposal: Sorted Vector Container
> --- In boost_at_y..., "Corwin Joy" <cjoy_at_h...> wrote:
> > Michael Gradman and myself have uploaded a new contaier to the
> > boost files area in a folder called vec_multiset.
> >
>
> One more comment.  So far, we have tested this with Visual C++ 6.0
> and GCC 2.96.
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
	I disagree.  One of the purposes of Boost is to create a body of
classes which can be standardized on (either formally or de facto). If
NullClass is widely useful, and apparently it is, as so far two projects
here have found a use for such a class, then it should, by itself, be a
feature of Boost, and all of us (at least) should standardize on that
one.
________________________________________________________________________
   From: "Vladimir Ciobanu" <psycho_at_[hidden]>
   They may be, but even if they are, I'd still rather keep separate
things
in separate parts of library.