[boost] MPL fold algorithms

[Gennadiy Rozental]

Hi,

Would it correct to state that following pseudo-code properly reflect the
essence of the appropriate algorithms:

iter_fold( sequence s, state st, binary_operator op ) {
   iterator it = s.begin();

   while( it != s.end() )
   st = op( st, it );
}

fold( sequence s, state st, binary_operator op ) {
   iterator it = s.begin();

   while( it != s.end() )
   st = op( st, *it );
}

iter_fold_backward( sequence s,
state st,
binary_operator backward_op,
binary_operator forward_op = identity ) {
   iterator it = s.begin();

   while( it != s.end() )
   st = forward_op( st, it );

   while( --it != s.begin() )
   st = forward_op( st, it );

st = forward_op( st, it );
}

fold_backward( sequence s,
  state st,
  binary_operator backward_op,
  binary_operator forward_op = identity ) {
   iterator it = s.begin();

   while( it != s.end() )
   st = forward_op( st, *it );

   while( --it != s.begin() )
   st = forward_op( st, *it );

st = forward_op( st, *it );
}

Gennadiy.

P.S. MPL docs reference pages does not formatted for printing. They does not
fit the page width. See iter_fold or example.





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

Re: [boost] [uBLAS] Interest in Possible Small RefactorisationContribution

[Toon Knapen]

On Friday 15 November 2002 05:46, Matt Davies wrote:

Could you post some code and or examples ?

> I noticed some minor duplication in vector.hpp so using cut & paste and
> a little inventiveness I have refactored scalar_vector, unit_vector and
> zero_vector into a single function_vector that takes a single
> vector_index_functor as its template argument. The benefits of this
> refactorisation is that users can further extend with instances of
> analytical functions / interpolants / whatever into a vector and it
> will use the uBLAS optimisations and constructs as appropriate. I have
> already been using it and *really* find it useful where I don't want to
> use excessive memory or less efficient constructs when calculating
> difference norms and/or resolving discretisations. It also saves a
> reasonable amount of duplication in vector.hpp.
>
> Furthermore, I suspect that it might not be an order of complexity
> further to create a function_matrix too based on the same ideas and for
> the same benefits.
>
> Is anyone interested in my work on this? I am guessing that the
> original maintainers probably have already thought of this as a lot of
> their work is still over my head. If anyone is interested and would
> like to guide and review my efforts (needed as this would potentially
> be my first open source contribution -- although small) I am happy to
> do more. I am hoping that (as it is mostly a cut&paste and as my
> original work closely copies the style of the rest of uBLAS) it would
> be easy to assimilate quickly.
>
> Matt
>
> http://careers.yahoo.com.au - Yahoo! Careers
> - 1,000's of jobs waiting online for you!
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] MPL remarks

[Gennadiy Rozental]

1. Copy reference page in a semantics section contains strange text. Are you
sure it is true?

2. Does compose facility gets tested anywhere?

3. MPL contains typeof implementation based on Bill Gibbons article. Don't
we want to factor it out to make it publically available?

4. It would be very helpul if headers defining the macros include short
purpose/usage description.

5. What is "void spec" noise is all about?

Enough for now.

Thanks,

Gennadiy.




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

Re: [boost] cyclic buffer

[Jan Gaspar]

Rob Stewart wrote:

> From: Jan Gaspar <[EMAIL PROTECTED]>
> >
> > This is something different - it is an iterator; if it reaches an end of the 
>container it shifts to its beginning. Cyclic buffer is a
> > container with different capabilities. I can send it to you, if you want.
>
> Of course it is.  However, since your circular buffer is merely
> adapting a deque, you could just as well use Gennadiy's iterator
> adapter to adapt the relevant (probably begin() and end())
> iterators of a deque or vector or  You could even change your
> implementation to use Gennadiy's iterator adapter.  Your class
> could be just a deque and an adapted iterator.

I could but I don't want to. I don't want to mix two different concepts: circular 
buffer and circular iterator. I think that circular
iterator is a standalone concept which can be used over any kind of container (even 
over circular buffer).

BTW I'm improving the circular buffer implementation - it will adapt a vector. This 
will result in performance increase and improvement of
iterator invalidation.

>
>
> > "Neal D. Becker" wrote:
> >
> > > This is from Gennadiy Rozental.  I believe this is the latest
> > > version. Please correct me if not.  Since it is small, I'll just post it here:
> > > ...
>
> --
> Rob Stewart   [EMAIL PROTECTED]
> Software Engineer http://www.sig.com
> Susquehanna International Group, LLP  using std::disclaimer;
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5443-5502 | Fax +421(2)5443-5512


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

[boost] Re: Relational tables: Ditto and RTL

[Arkadiy Vertleyb]

"Darryl Green" <[EMAIL PROTECTED]> wrote in message
news:50C88F08DFE7D611BB5C0060B0C4DD831426FD@;WNTX...

> I'm not entirely clear on what this means in practice. If I instantiate an
> operator using a table then add or delete elements from the table, I have
> violated the concept that all relations are constant objects. However,
> according to the (very good) docs all (?) that instantiating an operator
> does is to store references to its parameters (the tables). It is only
when
> I obtain and dereference (?) a relation iterator (using print, or calling
> begin() then dereferencing) that iteration over the tables occurs.

This is true in most cases.  However if you use indexing, instantiating of
such operator involvs building internal table (of iterators or keys) in
needed order.

> If I have tables which are not in fact const must I:
>
> a) Modify the tables and create new relation iterators
> OR
> b) Modify the tables and create new relation operators as well as
iterators
> OR
> c) Create the tables, operators and iterators from scratch whenever a
table
> changes

I think a) is generally expected.  In STL, iterators get invalidated when a
container changes.  In RTL you shold be fine with a) as long as you don't
use indexes.  If you do use indexes, they need to be updated whenever a
table changes.  With our current implementation that would mean going with
b)

This problem has two aspects:

1) We currently don't have the ability to incrementally update an index.
This should be easy to fix.
2) Some events should be broadcasted (probably using observer pattern) from
changing table to all indexes that depend on it, so that indexes are updated
together with the table.  Once this is implemented, you should be fine with
a)  in all cases.

> How concrete is the idea?

About as concrete as the above paragraph :-)

> As a potential user of some form of in-memory
> database that definitely needs relations/views based on multiple tables
and
> that will have insertions and deletions (not necessarily vast numbers of
> them) I'm very interested in this.

We need to better understand your requirements in order to adjust our
priorities.  Up until now, we were more focusing on the algebra than on
updating tables.  Therefore, updating tables is the area that definitly has
a huge room for improvement.

Arkadiy




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

Re: [boost] Can type_traits be user specialized?

[John Maddock]

> I have a problem however, which I think it would be useful to discuss
> generally.
>
> Unfortunately, some compilers -like bcc55- provide a 'default'
> numeric_limits<> with no compile-time constants, while the specializations
> do have compile-time values. Therefore, boost's numeric_limits<> is not
> picked up for these compilers; but trying to use numeric_limits<> with
user
> defined types fails to compile unless the types explicitly specialize it
> properly.
>
> I see three possible solutions here:
>
> (1) REQUIRE user defined types to *properly* specialize numeric_limits.
> (2) Enhance boost/limits.hpp so that it 'fixes' only the default
> numeric_limits<> if only that one is broken.
> (3) Define my own user specializable traits.
>
> (3) is IMO a very bad idea since we would end up with overlapping traits
and
> potential ODR violations.
> (2) might be a better solution but requires further examination.
> (1) is the easiest way to go from the library developer POV, but might
annoy
> users.

I don't actually think (2) is possible unfortunately, I would vote for (1),
it would be a precondition of your code that std::numeric_limits was
properly specialised, note however that there is at least one case (VC6 +
STLport) where numeric_limits constants are not usable in integral constant
expressions even for those templates that are specialised :-(

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm


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

Re: [boost] Re: Win32 regressions on main trunk updated

[John Maddock]

> What I was wondering about was whether the test machine (not mine, I'm
> still under MacOS 9.2.2 using CodeWarrior) had its headers properly
configured.
>
> The released version has BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
> defined for that compiler, but the main trunk version behaves as though
> such is not the case. Ergo, either it was found it should not have been
> defined, and the "#define" has been deleted between the release version
> and the main trunk, or the merging of the release trunk into the main
> trunk left out part of the config headers. Or I missed something...

Hubert, your code does not include  so no boost macros
will ever be set will they?

And yes the macros should be all set correctly - the config test cases are
all passing.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm


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

[boost] Re: Win32 regressions on main trunk updated

[Hubert HOLIN]

Somewhere in the E.U., le 15/11/2002

Bonjour

Something odd is going on... My code does include 
(on line 16 for both quaternion_test.cpp and octonion_test.cpp, on line
13 for quaternion_mi_test.cpp, though admitedly not yet for
quaternion_mi1.cpp, quaternion_mi2.cpp and HSO3SO4.cpp... I'll fix that
right now). I checked both my local copy and the (browser-visible) CVS copy.

Anyway, we should probably not loose to much sleep over that issue, as
a few other problems have been pointed out to me, so I am preparing
another batch of fixes.

A bientot

Hubert Holin
[EMAIL PROTECTED]

John Maddock wrote:
> 
> > What I was wondering about was whether the test machine (not mine, I'm
> > still under MacOS 9.2.2 using CodeWarrior) had its headers properly
> configured.
> >
> > The released version has BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
> > defined for that compiler, but the main trunk version behaves as though
> > such is not the case. Ergo, either it was found it should not have been
> > defined, and the "#define" has been deleted between the release version
> > and the main trunk, or the merging of the release trunk into the main
> > trunk left out part of the config headers. Or I missed something...
> 
> Hubert, your code does not include  so no boost macros
> will ever be set will they?
> 
> And yes the macros should be all set correctly - the config test cases are
> all passing.
> 
> John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm
> 
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

RE: [boost] MPL lambda

[Aleksey Gurtovoy]

Rozental, Gennadiy wrote:
> I am having hard time grasping how this %#$% lambda facility 
> is working. 

I hope you mean "what it does/how to use it" as opposite to "how it does
what it does" ;).

> Unfortunally paper does not provide enough information. 
> Could you at least provide general scetch? Amoung other things I 
> would like to know when I need to use _ and when _1,_2,...? 

The numbered placeholders (_1, _2, ...) have the same semantics as those in
equivalent run-time libraries, Boost.Bind and Boost.Lambda. You can always
use them and forget about unnamed form (_). The only real value associated
with the latter is its visual appeal :). 

The "table" below demonstrates the semantics of both forms:

// numbered placeholders semantics
plus<_1, int_c<5> > == bind,_1,int_c<5> >
plus< int_c<5>,_1 > == bind,int_c<5>,_1 >
plus< int_c<5>,_2 > == bind,int_c<5>,_2 >
plus<_1,_2> == bind,_1,_2>
plus<_2,_1> == bind,_2,_1>

logical_or< is_same<_1,int>, is_same<_1,long> >
= bind< meta_fun2
, bind< meta_fun2,_1,int >
, bind< meta_fun2,_1,long >
>

is_same< _1, add_pointer<_2> >
== bind< meta_fun2
, _1
, bind< meta_fun1, _2 >
>

// unnamed placeholder semantics
plus< _,int_c<5> > == plus<_1, int_c<5> >
plus< int_c<5>,_ > == plus< int_c<5>,_1 >
??? == plus< int_c<5>,_2 > // can't be built using unnamed notation
plus<_,_> == plus<_1,_2> 
??? == plus<_2,_1> 

logical_or< is_same<_,int>, is_same<_,long> >
= logical_or< is_same<_1,int>, is_same<_1,long> >

is_same< _, add_pointer<_> > != is_same< _1, add_pointer<_2> > // !!!
is_same< _, add_pointer<_> >
== bind< meta_fun2
, _1
, bind< meta_fun1, _1 > // !!!
>


> Could you write in a form of step by step description how 
> fold-family algorithms are working? 

>From the reference docs
(http://www.mywikinet.com/mpl/ref/Reference/iter_fold.html):

Expression 
~~

typedef iter_fold::type t;

Semantics 
~

Equivalent to 

typedef lambda::type op; 
typedef begin::type i1; 
typedef apply::type t1; 
typedef i1::next i2; 
typedef apply::type t2; 
...
typedef apply::type tn; 
typedef in::next last; 
typedef tn t;

, where n == size::type::value and last is identical to
end::type; 

Equivalent to typedef T t; if the sequence is empty.


> Also is there gen_scattered/linear_hierarchy implementation 
> somewhere for MPL sequenses?

MPL's 'inherit_linearly' algorithm + 'inherit' metafunction (in the CVS now)
cover both of these. Please see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/example/inherit_linearly.cpp and
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/example/inherit_multiply.cpp for the corresponding examples.

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

Re: [boost] Re: Win32 regressions on main trunk updated

[David Abrahams]

Hubert HOLIN <[EMAIL PROTECTED]> writes:

> Somewhere in the E.U., le 15/11/2002
>
>   Bonjour
>
>   Something odd is going on... My code does include
>  (on line 16 for both quaternion_test.cpp and
> octonion_test.cpp, on line 13 for quaternion_mi_test.cpp, though
> admitedly not yet for quaternion_mi1.cpp, quaternion_mi2.cpp and
> HSO3SO4.cpp... I'll fix that right now). I checked both my local
> copy and the (browser-visible) CVS copy.

That's a very strange approach. Usually these config headers must be
#included in boost headers, not source files... (?)

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] Proposed Boost Assert -- once again

[Peter Dimov]

From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
> Peter Dimov writes:
>
> > what is the intended audience of BOOST_ASSERT, Boost library developers
> > or "end users"?
>
> Both.  I would like a uniform way of handling assertions / tests of
> preconditions in Boost libraries, and I would also like to be able to use
> it in application code.

OK, let me rephrase that. What is the primary audience of BOOST_ASSERT?
Making it more suitable for application-level use may mean that it becomes
unacceptable for some Boost libraries. We don't want that. :-) So I've
adopted a fairly conservative approach.

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

RE: [boost] MPL fold algorithms

[Aleksey Gurtovoy]

Gennadiy Rozental wrote:
> Would it correct to state that following pseudo-code properly 
> reflect the essence of the appropriate algorithms:
> 
> iter_fold( sequence s, state st, binary_operator op ) {
>iterator it = s.begin();
> 
>while( it != s.end() )
>st = op( st, it );

return st;
> }

> fold( sequence s, state st, binary_operator op ) {
>iterator it = s.begin();
> 
>while( it != s.end() )
>st = op( st, *it );

return st;
> }


> iter_fold_backward( sequence s,
> state st,
> binary_operator backward_op,
> binary_operator forward_op = identity ) {
>iterator it = s.begin();
> 
>while( it != s.end() )
>st = forward_op( st, it );
> 
>while( --it != s.begin() )
>st = forward_op( st, it );
> 
> st = forward_op( st, it );

return st;
> }


> 
> fold_backward( sequence s,
>   state st,
>   binary_operator backward_op,
>   binary_operator forward_op = identity ) {
>iterator it = s.begin();
> 
>while( it != s.end() )
>st = forward_op( st, *it );
> 
>while( --it != s.begin() )
>st = forward_op( st, *it );
> 
> st = forward_op( st, *it );

return st;
> }


Yep, that's basically what they do.


> P.S. MPL docs reference pages does not formatted for 
> printing. They does not fit the page width. See iter_fold or example.

Yep, it's a known problem. The new revision will come in PDF (properly
formatted) as well as HTML, so it won't be an issue then.

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

Re: [boost] Proposed Boost Assert -- once again

[Peter Dimov]

From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
>
> 1. The proper C++ header file is , not .

True. The "improper" header has the advantage that it's universally
available, though, and there is no other difference between the two, as the
macro assert isn't std-namespaced.

> 2. I think using familiar terminology is preferable.  Developers already
> know what NDEBUG does and how to use it, so I would prefer that
> BOOST_DISABLE_ASSERTS be renamed BOOST_NDEBUG.

No strong opinion, although I find it hard to believe that BOOST_NDEBUG
could be more understandable than BOOST_DISABLE_ASSERTS.

> > there is no explicit support for throwing exceptions, and no standard
> > exception class is defined. (Although it is trivial to define a handler
> > that throws.) This is intentional. I don't believe that we, at Boost,
want
> > to encourage this particular programming practice (assertions that
throw.)
>
> I disagree, on two counts:
>
> 1. I've dealt with enterprise systems that do some run-time checks, but
> for which crashing and core-dumping is not an option.  In this case it is
> preferred to abort the transaction (throw an exception), log the error,
> and get on with handling other transactions.

Agreed. This is why the capability is supported. assertion_failed() is
allowed to throw.

This doesn't mean that in general throwing exceptions when assertions fail
is a good programming practice. Far from it.

Providing direct support in a Boost core header effectively amounts to a
"Boost seal of approval", i.e. "we at Boost think that this is a good
programming practice and we want to encourage its use." Do we? I certainly
don't.

> 2. A number of the Boost libraries currently throw exceptions for logical
> errors.  During development, I would rather that these do an assert(), so
> I can inspect the core dump with my debugger.  Rather than fight over
> which is the correct behavior, it seems preferable to simply make it a
> user option.  I've been counting on Boost Assert to provide that
> functionality.

Fighting for which is the correct behavior is the Right Thing(tm) to do.
First, because it will improve the libraries in question, second, because
BOOST_ASSERT affects _all_ Boost libraries.

> One might argue that a user can always get throwing behavior by using
> BOOST_ENABLE_ASSERT_HANDLER, but I am of the opinion that one should
> provide some standard options for commonly-desired behavior.

Yes, that is exactly what I am arguing. Throwing an exception from
BOOST_ASSERT is undesired behavior. I don't want it as a standard option.

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

RE: [boost] MPL remarks

[Aleksey Gurtovoy]

Gennadiy Rozental wrote:
> 1. Copy reference page in a semantics section contains 
> strange text. Are you sure it is true?

Yes :). Citing the "Description" section:

"copy is, in fact, just another name for fold. It was introduced for
symmetry with copy_if [1], and because it's a nice name for one of the
typical fold applications, that is, copying the content of one sequence into
another - see the example below."


> 2. Does compose facility gets tested anywhere?

It was. At some point these templates were near extinction, but somehow they
survived ;). I'll revise the issue for the next revision of the library -
thanks for reminding.

> 3. MPL contains typeof implementation based on Bill Gibbons 
> article. Don't we want to factor it out to make it publically available?

I am not sure how useful it is outside the library - it's pretty simplistic.
If anybody wants it, they are welcome to do the refactoring.

> 
> 4. It would be very helpul if headers defining the macros 
> include short purpose/usage description.

Fair enough. Consider it fixed.

> 
> 5. What is "void spec" noise is all about?

It's a long story. If you are working with a conforming compiler, you can
ignore it. If not, I will explain :).

Thanks for you comments!
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Can type_traits be user specialized?

[Fernando Cacciola]

- Original Message -
From: "John Maddock" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 8:40 AM
Subject: Re: [boost] Can type_traits be user specialized?


> > I have a problem however, which I think it would be useful to discuss
> > generally.
> >
> > Unfortunately, some compilers -like bcc55- provide a 'default'
> > numeric_limits<> with no compile-time constants, while the
specializations
> > do have compile-time values. Therefore, boost's numeric_limits<> is not
> > picked up for these compilers; but trying to use numeric_limits<> with
> user
> > defined types fails to compile unless the types explicitly specialize it
> > properly.
> >
> > I see three possible solutions here:
> >
> > (1) REQUIRE user defined types to *properly* specialize numeric_limits.
> > (2) Enhance boost/limits.hpp so that it 'fixes' only the default
> > numeric_limits<> if only that one is broken.
> > (3) Define my own user specializable traits.
> >
> > (3) is IMO a very bad idea since we would end up with overlapping traits
> and
> > potential ODR violations.
> > (2) might be a better solution but requires further examination.
> > (1) is the easiest way to go from the library developer POV, but might
> annoy
> > users.
>
> I don't actually think (2) is possible unfortunately, I would vote for
(1),
> it would be a precondition of your code that std::numeric_limits was
> properly specialised,

OK. I'll go for (1) then.

> note however that there is at least one case (VC6 +
> STLport) where numeric_limits constants are not usable in integral
constant
> expressions even for those templates that are specialised :-(
>
Hugh!
Is this fixed by "boost/limits.hpp"?

Anyway, in the worst case, I think it is always possible to fix
numeric_limits at the user side.


> John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/index.htm
>
>

Thanks.

Fernando Cacciola

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

[boost] Named Template Parameters implementation

[Fernando Cacciola]

Hi All!

As a final touch in the Numeric Conversion library I have almost ready, I
want to add it named template parameters for easier usage.
Were can I borrow the State of the Art implementation of this idiom from?

TIA,

Fernando Cacciola

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

[boost] Re: DocBook/XML Reference Documentation updates

[James Curran/MVP]

These are generated from XML, correct?  If so, could you include a link
to the source XML?

Also, on the HTML, all the graphic seem to point to broken links.

--
Truth,
James Curran
www.NovelTheory.com  (Personal)
www.NJTheater.com   (Professional)
www.aurora-inc.com   (Day job)


"Douglas Gregor" <[EMAIL PROTECTED]> wrote in message
news:200211150156.38481.gregod@;cs.rpi.edu...
> Hello all,
>   I've improved the DocBook-based reference documentation a bit more.
Changes
> & new features:
>   - Ability to use the Docbookesque foo to create a
> link to the class named "foo" (as defined in a reference section) within
> text, function signatures, etc.
>   - Better support for syntax highlighting
>   - Better support for man pages
>
> The current HTMLized version of the Boost.Function docs (incomplete, but
> getting closer...) is here:
>   http://www.cs.rpi.edu/~gregod/Boost/function-html/
>
> The man pages (very much improved!) are available here:
>   http://www.cs.rpi.edu/~gregod/Boost/function-man/
>
> Is this the way we want to go with documentation? Should we explore other
> options (e.g., LaTeX) further, or is there any other part of the system we
> need to see working before we can choose? We need a better documentation
> solution for Boost, but if developers think we are going the wrong way and
> won't use it (and don't speak up), then the situation is dire indeed.
>
> Doug
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>




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

[boost] Re: Win32 regressions on main trunk updated

[Hubert HOLIN]

Somewhere in the E.U., le 15/11/2002

Bonjour

David Abrahams wrote:
> 
> Hubert HOLIN <[EMAIL PROTECTED]> writes:
> 
> > Somewhere in the E.U., le 15/11/2002
> >
> >   Bonjour
> >
> >   Something odd is going on... My code does include
> >  (on line 16 for both quaternion_test.cpp and
> > octonion_test.cpp, on line 13 for quaternion_mi_test.cpp, though
> > admitedly not yet for quaternion_mi1.cpp, quaternion_mi2.cpp and
> > HSO3SO4.cpp... I'll fix that right now). I checked both my local
> > copy and the (browser-visible) CVS copy.
> 
> That's a very strange approach. Usually these config headers must be
> #included in boost headers, not source files... (?)

Well, it was intentional, if not very smart.

The idea was that the config files essentially allowed workarounds for
platform deficiencies, so if your platform was conformant, you did not
need them. Including the config from the headers hides from the user his
platform's deficiencies, whereas he should be (painfully) aware of them
so as to complain to his vendor. Having to include the config files in
user code was supposed to raise awareness of the problem. Of course, for
the test files, they must be present.

If this is found to be confusing or unwieldly, I can change.

A bientot

Hubert Holin
[EMAIL PROTECTED]

> --
>David Abrahams
>[EMAIL PROTECTED] * http://www.boost-consulting.com
> Boost support, enhancements, training, and commercial distribution
> 
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

Re: [boost] Re: DocBook/XML Reference Documentation updates

[Douglas Gregor]

On Friday 15 November 2002 09:51 am, James Curran/MVP wrote:
> These are generated from XML, correct?  If so, could you include a link
> to the source XML?

Yep, yep, and here:
  http://www.cs.rpi.edu/~gregod/Boost/function.xml

It's mostly a DocBook document, but the  tag is C++ class (template) 
definition and function (template) declaration XML used to generate the 
reference section. The full example (including DocBook-only elements like the 
tutorial) and the actual XSLT stylesheets are in the sandbox 
(libs/documentation).

> Also, on the HTML, all the graphic seem to point to broken links.

Forgot to upload those. The links shouldn't be broken any more.

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

Re: [boost] Named Template Parameters implementation

[Jaakko Jarvi]

On Fri, 15 Nov 2002, Fernando Cacciola 
wrote:
 
> As a final touch in the Numeric Conversion library I have almost ready, I
> want to add it named template parameters for easier usage.
> Were can I borrow the State of the Art implementation of this idiom from?

Don't know about state of the art, but this library tries to do a 
decent job:

libs/named_template_parameters in boost sandbox. 

/Jaakko


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

[boost] Re: Copy Constructible Concept

[Gennaro Prota]

On Tue, 29 Oct 2002 16:24:19 -0500, Douglas Gregor <[EMAIL PROTECTED]>
wrote:

>On Tuesday 29 October 2002 04:10 pm, Kevin S. Van Horn wrote:
>> Why are requirements about the address operator (&) included in the
>> CopyConstructible concept at
>> http://www.boost.org/libs/utility/CopyConstructible.html?  This strikes me
>> as an error of taxonomy, as there is no essential reason why the two
>> issues belong together.  There are many algorithms that require one to be
>> able to copy values, but don't care about taking addresses, and we have
>> boost::addressof() anyway.
>
>The requirements in utility/CopyConstructible.html are the same as those in 
>the C++ standard. FWIW, I agree with you that the address-of operator should 
>not be included, and I recently (last week) filed a defect report against it. 
>Only time will tell

I don't see the reason for the inclusion of operator & either. However
if really that reason doesn't exist it is *vry* strange that this
wasn't noticed during discussions about library issue 69:

 http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#69

The rationale section for that defect says:

There is no need to explicitly consider a user-defined operator&
because elements must be copyconstructible (23.1
[lib.container.requirements] para 3) and copyconstructible (20.1.3
[lib.copyconstructible]) specifies requirements for operator&.

How is it possible for it to pass unnoticed?

Genny.


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

[boost] Re: boost::graph - incorrect answers withdikjstra_shorts_paths

[Marc Jacobs]

Thanks, Jeremy. I appreciate any help you can provide...
Marc

"Jeremy Siek" <[EMAIL PROTECTED]> wrote in message
news:2147483647.1037316564@;[192.168.1.102]...
> Hi Marc,
>
> I don't have time to look at this right now, but I'll try to get to it
this
> weekend.
>
> Regards,
> Jeremy
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>




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

Re: [boost] DocBook/XML Reference Documentation updates

[Douglas Gregor]

On Friday 15 November 2002 01:56 am, Douglas Gregor wrote:
> The current HTMLized version of the Boost.Function docs (incomplete, but
> getting closer...) is here:
>   http://www.cs.rpi.edu/~gregod/Boost/function-html/
>
> The man pages (very much improved!) are available here:
>   http://www.cs.rpi.edu/~gregod/Boost/function-man/

And now some (imperfect, but pretty good) print documentation:
http://www.cs.rpi.edu/~gregod/Boost/function.pdf

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

Re: [boost] Named Template Parameters implementation

[Fernando Cacciola]

> Don't know about state of the art, but this library tries to do a
> decent job:
>
> libs/named_template_parameters in boost sandbox.
>
Opps! In my previous message (hope it arrives before this one); I asked you
to give me an example of how to use it...
But I missed the "/lib" part... I just looked at the header file.
Sorry.

Fernando Cacciola


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

Re: [boost] Named Template Parameters implementation

[Fernando Cacciola]

- Original Message -
From: "Jaakko Jarvi" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 12:18 PM
Subject: Re: [boost] Named Template Parameters implementation


>
> On Fri, 15 Nov 2002, Fernando Cacciola
> wrote:
>
> > As a final touch in the Numeric Conversion library I have almost ready,
I
> > want to add it named template parameters for easier usage.
> > Were can I borrow the State of the Art implementation of this idiom
from?
>
> Don't know about state of the art, but this library tries to do a
> decent job:
>
> libs/named_template_parameters in boost sandbox.
>

Yep, I've seen it... Looks pretty good.

I think I figured out how to use it.. But, do you have at hand a sample
usage of it?

And,

Can I borrow this header and include it in the submission package for the
Numeric Conversion library?
Or do you prefer that we review it stand alone first?


> /Jaakko

Thanks,

Fernando Cacciola

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

[boost] Re: Serialization Library Review

[Thomas Matelich]

Disclaimer:  I haven't read any other reviews or much of the discussion of
this library so I can't say if my issues have already been covered.

Serialization Review

I haven't participated in any reviews for a long time, so I thought I'd
tackle this one.  Conveniently, I had a little tool that was ready for some
serialization, all it has is a vector of objects which each have another
subvector of strings, give or take.  I read the introduction and skimmed the
tutorial.  I jumped in and wrote my save function.  And that is where my
review ends.  You see, I was working on MSVC 6 sp 5, and apparently, it is
not supported.  Granted, I only gave it a half hearted try.

The first error I received was from void_cast.hpp from

// without the following tweak - builds with /Ob2 - ie release builds
// will crash in serialization_imp.hpp
#ifdef BOOST_MSVC
__declspec(noinline)
#endif

which gave:
.\boost/void_cast.hpp(179) : error C2485: 'noinline' : unrecognized extended
attribute
.\boost/void_cast.hpp(184) : see reference to class template
instantiation
'boost::void_cast_detail::void_caster_primitive' being
compiled

I happily commented it out since this tool would only be used with debug
builds.

Continuing on, I recieved several:

.\boost/serialization/archive.hpp(184) : error C2061: syntax error :
identifier 'T'

and a couple like:

.\boost/serialization/archive.hpp(196) : error C2535: 'void __thiscall
boost::basic_oarchive::register_type(void)' : member function already
defined or declared
.\boost/serialization/archive.hpp(185) : see declaration of
'register_type'

Anyway, seemed like a nice package for general use.  My company is currently
in love with XML, so I probably wouldn't be using it for our commercial
products.

The documentation seems fairly clear, though I would strike the comment
about Holub.

My vote is neutral-positive.  I am in favor of a library supporting this,
but I didn't spend enough time on it to say for sure that this is the one.

Tom Matelich

//pardon the disclaimer...




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

[boost] String algorithm library

[Pavol Droba]

Hi Boosters,

I have developed a set of various string manipulating functions into a string_algo 
lib. 
The choice is partly based on the discussion here in the boost list. 
The implementaion is currently in the sandbox in the boost/string_algo.hpp header and 
boost/string_algo dir.

There is a small example and tests in the sandbox/lib/string_algo.
Currently there is no real documentation, because the lib is in early stage of 
development
and so it could change quite repidly. The best source of usage scenario are the the 
tests.

Library has been tested with VC7 and gcc3.2 on cygwin.

As there has been an interest I'd like to ask you if such a library should become a 
part of boots
in the future. I'd be happy to hear any opinions and suggestions.

The library contains following functions divided by categories. 
Functions with _in suffix provide in-place transformation.
For each Find-Replace category function there is a variant with implicit Comp 
predicate defaulting
to == operator functor

Trimming:

   Iterator trim_begin( Iterator InBegin, Iterator InEnd, const std::locale& 
Loc=std::locale() )
   Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
   Seq& ltrim_in( Seq& Input, const std::locale& Loc=std::locale() )
   Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
   Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
   Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
   Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )

Case conversion:

   Seq tolower( const Seq& Input, const std::locale& Loc=std::locale() )
   Seq& tolower_in( Seq& Input, const std::locale& Loc=std::locale() )
   Seq toupper( const Seq& Input, const std::locale& Loc=std::locale() )
   Seq& toupper_in( Seq& Input, const std::locale& Loc=std::locale() )

Predicates:

   bool start_with( 
InputIterator Begin,  InputIterator End, 
  SubIterator SubBegin, SubIterator SubEnd,
  BinaryPredicate Comp )
bool start_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate Comp )
bool end_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate Comp )
bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate Comp )

Find-Replace:

std::pair find( 
InputIterator Begin, InputIterator End, 
SubIterator SubBegin, SubIterator SubEnd,
BinaryPredicate Comp )

std::pair 
find_first( 
const Seq1& Input, 
const Seq2& Substr,
BinaryPredicate Comp )

std::pair find_first( 
Seq1& Input, 
const Seq2& Substr,
BinaryPredicate Comp )

std::pair 
find_last( 
const Seq1& Input, 
const Seq2& Substr,
BinaryPredicate Comp )

std::pair find_last( 
Seq1& Input, 
const Seq2& Substr,
BinaryPredicate Comp )

typename InputSeq::iterator replace_substr(
InputSeq& Input,
typename InputSeq::iterator From,
typename InputSeq::iterator To,
ReplSeq& Repl )

void replace_first(
InputIterator Begin, InputIterator End,
MatchIterator MatchBegin, MatchIterator MatchEnd,
ReplIterator ReplBegin, ReplIterator ReplEnd,
OutputIterator Output,
BinaryPredicate Comp )

InputSeq replace_first( 
const InputSeq& Input,
const MatchSeq& Match,
const ReplSeq& Repl,
BinaryPredicate Comp )

InputSeq& replace_first_in( 
InputSeq& Input,
const MatchSeq& Match,
const ReplSeq& Repl,
BinaryPredicate Comp )

InputSeq& replace_first_in( 
InputSeq& Input,
const MatchSeq& Match,
const ReplSeq& Repl )

void replace_all(
InputIterator Begin, InputIterator End,
MatchIterator MatchBegin, MatchIterator MatchEnd,
ReplIterator ReplBegin, ReplIterator ReplEnd,
OutputIterator Output,
BinaryPredicate Comp )

InputSeq replace_all( 
const InputSeq& Input,
const MatchSeq& Match,
const ReplSeq& Repl,
BinaryPredicate Comp )

InputSeq& replace_all_in( 
InputSeq& Input,
const MatchSeq& Match,
const ReplSeq& Repl,
BinaryPredicate Comp )

void erase_first(
InputIterator Begin, InputIterator End,
MatchIterator MatchBegin, MatchIterator MatchEnd,
OutputIterator Output,
BinaryPredicate Comp )

InputSeq erase_first( 
const InputSeq& Input,
  

[boost] Reminder: Serialization Library Review

[David Abrahams]

This is a reminder that the review of Robert Ramey's serialization
Library will be ending on Monday, 18 November. Please post your review
comments with a vote before that time.

--

Here is an introductory paragraph describing the library, from its
documentation.

   In this system, we use term "serialization" to mean a system where
   the current state of group of objects can be stored to a permanent
   medium that may outlast the current program execution. At any later
   time an equivalent group of objects can be restored from the
   permanent medium. It is the goal of this system to permit this
   facility to be included in any C++ program with a minimium of
   additional effort.


Here's a reminder of what to include in your review comments:

   Your comments may be brief or lengthy, but basically the Review
   Manager needs your evaluation of the library.  If you identify
   problems along the way, please note if they are minor, serious, or
   showstoppers.

   Here are some questions you might want to answer in your review:

  What is your evaluation of the design?

  What is your evaluation of the implementation?

  What is your evaluation of the documentation?

  What is your evaluation of the potential usefulness of the
  library?

  Did you try to use the library?  With what compiler?  Did you
  have any problems?

  How much effort did you put into your evaluation? A glance? A
  quick reading? In-depth study?

  Are you knowledgeable about the problem domain? 

   And finally, every review should answer this question:

  Do you think the library should be accepted as a Boost library?
  Be sure to say this explicitly so that your other comments don't
  obscure your overall opinion.

You can download the library submission from
http://groups.yahoo.com/group/boost/files/serialization6.zip

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

[boost] Re: MPL lambda

[Dirk Gerrits]

Aleksey Gurtovoy wrote:


Rozental, Gennadiy wrote:

>Also is there gen_scattered/linear_hierarchy implementation
>somewhere for MPL sequenses?


MPL's 'inherit_linearly' algorithm + 'inherit' metafunction (in the 
CVS now)
cover both of these. Please see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/example/inherit_linearly.cpp and
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/example/inherit_multiply.cpp for the corresponding examples.

This is some very cool stuff!

However, the way I understand it, inherit_linearly takes a type sequence 
(like mpl::list) as an argument and inherit takes the types themselves 
as arguments. I'd like to have an inherit that takes a type sequence as 
an argument, instead of or in addition to the current inherit. This is 
because I need to do some Modern-C++-Design-ish stuff which needs a 
scattered hierarchy instead of a linear one.

Regards,
Dirk Gerrits



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

Re: [boost] Named Template Parameters implementation

[Jaakko Jarvi]

> > Don't know about state of the art, but this library tries to do a
> > decent job:
> >
> > libs/named_template_parameters in boost sandbox.
> >
> Opps! In my previous message (hope it arrives before this one); 

No it didn't :)

I asked you
> to give me an example of how to use it...
> But I missed the "/lib" part... I just looked at the header file.

Yes, the documentation is quite detailed. That's actually what the 
"library" really is, a set of conventions. The header is really tiny.

The intention was to submit named parameters as a separate library. It was
already discussed some months ago. There was some controversy, mainly 
someone wanted even more general mechanism, which was syntactically a bit
heavier.

I'll look through the code and docs and see 
if all still makes sense. If so I'll go ahead and request a 
formal review. And if you need the library now, just go ahead and grab 
it and use it. It's just a one small include file, the location of which 
is easy to change, if it becomes a boost library, instead of an internal 
part of your library. 

/Jaakko


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

[boost] Re: Serialization Library Review

[Dirk Gerrits]

Thomas Matelich wrote:


Anyway, seemed like a nice package for general use.  My company is 
currently in love with XML, so I probably wouldn't be using it for our 
commercial products.

Maybe you missed it due to only skimming the documentation, but it is 
possible to write your own archive types for use with the library. An 
XML output archive should be pretty easy, and I imagine that given an 
XML parser, an input archive should also be quite feasable.

Regards,
Dirk Gerrits



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

Re: [boost] Proposed Boost Assert -- once again

[Kevin S. Van Horn]

Peter Dimov writes:

> Making [Boost Assert] more suitable for application-level use may mean
> that it becomes unacceptable for some Boost libraries.

Can you give me a for-instance?  I don't see the conflict.


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

Re: [boost] Re: MPL lambda

[Mat Marcus]

Scatter hierarchies can be achieved by using inherit_linearly 
together with mpl::inherit. See the second example that Aleksey 
cited *is* an example of a scatter hierarchy.




--On Friday, November 15, 2002 5:28 PM +0100 Dirk Gerrits 
<[EMAIL PROTECTED]> wrote:

Aleksey Gurtovoy wrote:


Rozental, Gennadiy wrote:

> Also is there gen_scattered/linear_hierarchy implementation
> somewhere for MPL sequenses?


MPL's 'inherit_linearly' algorithm + 'inherit' metafunction
(in the  CVS now)
cover both of these. Please see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/bo
ost/boost/libs/m pl/example/inherit_linearly.cpp and
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/bo
ost/boost/libs/m pl/example/inherit_multiply.cpp for the
corresponding examples.


This is some very cool stuff!

However, the way I understand it, inherit_linearly takes a
type sequence (like mpl::list) as an argument and inherit
takes the types themselves as arguments. I'd like to have an
inherit that takes a type sequence as an argument, instead of
or in addition to the current inherit. This is because I need
to do some Modern-C++-Design-ish stuff which needs a
scattered hierarchy instead of a linear one.

Regards,
Dirk Gerrits



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



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

Re: [boost] Proposed Boost Assert -- once again

[Kevin S. Van Horn]

Peter Dimov write:

> > 1. The proper C++ header file is , not .
> 
> True. The "improper" header has the advantage that it's universally
> available, though, and there is no other difference between the two,

I don't want to make a mountain out of a molehill, but I believe there is 
a difference between the two:  is part of the C++ Standard, and 
 is not.  Strictly speaking, use of  is not 
standard-conforming, and Boost code is supposed to be standard-conforming.

> Throwing an exception from BOOST_ASSERT is undesired behavior. I don't
> want it as a standard option.

Except that, in the case I pointed out, it sometimes is desired behavior 
and the Right Thing(tm) to do.  One aborts an entire subcomputation / 
transaction rather than aborting the entire program.  I expect this to be 
the norm, not the exception (pardon the pun), for enterprise information 
systems.  Because it is a common, important case, it is desirable that we 
provide a standard solution for this case.  If you like, the documentation 
can make it clear exactly under which circumstances use of the 
exception-throwing behavior is desirable, and when it is not.






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

Re: [boost] Re: Serialization Submission version 6

[William E. Kempf]

David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> David Abrahams said:
>>> "Eric Woodruff" <[EMAIL PROTECTED]> writes:
>>>
 type_info is not portable in the slightest.
>>>
>>> There are lots of applications where that doesn't matter. And with a
>>> little postprocessing, the type_info::name() produced by most
>>> compilers could easily be normalized into a common format.
>>
>> The trouble is that serialization requires an identifier that's
>> persistant across application runs.
>
> Not all uses of serialization depend on that.

Most of the cases I've ever had a need for do.  Either it's being used to
persist data, or it's being used to do IPC.  Are the other uses really
prevalent in your experience?

>> type_info by itself doesn't help here, because you can't persist the
>> type_info instance even if it were gauranteed to compare across runs
>> (obviously it's not).  type_info::name() is so underspecified that you
>> can't be sure it won't give you the same string for every type. More
>> importantly, in practice (i.e. implementations do this),
>> type_info::name() will often give you strings that are *not* unique,
>> rendering it worthless for this domain.
>
> Which implementations? Boost.Python v2 /depends/ on type_info::name()
> returning a usefully-unique string on many platforms (depending on their
> dynamic linking model). I've never seen an example of a platform which
> "often give you strings that are *not* unique", but if they're out
> there, I need to know about them.

OK, I may be wrong here.  However, it was my understanding that many
implementation returned nothing more than the type's name, minus the
namespace, which would mean you could easily get non-unique names.  I had
even heard a rumor once that there was a compiler that always returned a
null string, in order to save space in the executable, but I can't tell
you what compiler that was supposed to be or verify that it was anything
more than a bad rumor.

Regardless, however, you have to admit that all of this *IS* allowed by
the standard, making relying on this behavior to be shaky even if you
could confirm that all current implementations do something useful here.

>> Can type_info::name() be useful?  Yes, provided the implementation did
>> something useful, but it's not portable, and not useful for the task
>> at hand.
>
> There are lots of tasks you can do with a serialization library, and I
> submit that a reasonable proportion of those tasks can take advantage of
> type_info::name() on a useful number of compilers.

If type_info:name() doesn't return a unique string?

>> BTW, there's a LOT to be said for specifically supplying an
>> identifier when implementing a persistence/serialization library, even
>> though it means tedious busy work.  Specifically, it allows you to
>> insure the id is valid across multiple programs, regardless of how the
>> implementation might auto-magically generate an identifier. I'd
>> recommend choosing a "large integer" representation instead of a
>> string, however, since it will take less space to represent
>> externally.  The GUID type is actually a fairly good choice here.
>
> Maybe it would make sense to use Steve Dewhurst's typeof()
> technique. At least that could help reduce the number of user-supplied
> identifiers needed.

That may well be worth looking into, but I'm not familiar with the
technique.  I know he generates unique integer ids (or at least, I think I
know that), but will the generation produce consistent ids across
application runs?  If not, regardless of whether or not serialization can
be useful with out that, I would claim it cripples the serialization
library enough to not be a valid solution.

William E. Kempf



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

Re: [boost] Re: MPL lambda

[Dirk Gerrits]

Mat Marcus wrote:


Scatter hierarchies can be achieved by using inherit_linearly together
with mpl::inherit. See the second example that Aleksey cited *is* an
example of a scatter hierarchy.


Forgive me, I hadn't realized this. That's just too cool! :) Thanks.

Regards,
Dirk Gerrits

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

Re: [boost] Proposed Boost Assert -- once again

[David Abrahams]

"Kevin S. Van Horn" <[EMAIL PROTECTED]> writes:

> Peter Dimov write:
>
>> > 1. The proper C++ header file is , not .
>> 
>> True. The "improper" header has the advantage that it's universally
>> available, though, and there is no other difference between the two,
>
> I don't want to make a mountain out of a molehill, but I believe there is 
> a difference between the two:  is part of the C++ Standard, and 
>  is not.  Strictly speaking, use of  is not 
> standard-conforming

Nope. One of the main design goals of C++ was that many normal 'C'
language programs should compile without modification.  Removing the
'C' language  headers would totally undermine that. Every 'C'
hello world starts with:

#include 

So C++ includes all of the 'C' headers.


-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] Re: Serialization Submission version 6

[David Abrahams]

"William E. Kempf" <[EMAIL PROTECTED]> writes:

> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> Not all uses of serialization depend on that.
>
> Most of the cases I've ever had a need for do.  Either it's being used to
> persist data, or it's being used to do IPC.  Are the other uses really
> prevalent in your experience?

No, I didn't claim they were. I'm just saying that they exist. Where
applicable, it's important to be able to avoid a lot of extra work
writing registration code.

>> Which implementations? Boost.Python v2 /depends/ on
>> type_info::name() returning a usefully-unique string on many
>> platforms (depending on their dynamic linking model). I've never
>> seen an example of a platform which "often give you strings that
>> are *not* unique", but if they're out there, I need to know about
>> them.
>
> OK, I may be wrong here.  However, it was my understanding that many
> implementation returned nothing more than the type's name, minus the
> namespace, which would mean you could easily get non-unique names.
> I had even heard a rumor once that there was a compiler that always
> returned a null string, in order to save space in the executable,
> but I can't tell you what compiler that was supposed to be or verify
> that it was anything more than a bad rumor.
>
> Regardless, however, you have to admit that all of this *IS* allowed
> by the standard, making relying on this behavior to be shaky even if
> you could confirm that all current implementations do something
> useful here.

Yep, it's legally shaky. I think it's relatively portable, practically
speaking.

>>> Can type_info::name() be useful?  Yes, provided the implementation
>>> did something useful, but it's not portable, and not useful for
>>> the task at hand.
>>
>> There are lots of tasks you can do with a serialization library,
>> and I submit that a reasonable proportion of those tasks can take
>> advantage of type_info::name() on a useful number of compilers.
  ^^^
>
> If type_info:name() doesn't return a unique string?

No, but show me one example which doesn't. My point is that most
compilers do emit unique strings for all practical purposes. Most even
do something human-readable.

>>> BTW, there's a LOT to be said for specifically supplying an
>>> identifier when implementing a persistence/serialization library, even
>>> though it means tedious busy work.  Specifically, it allows you to
>>> insure the id is valid across multiple programs, regardless of how the
>>> implementation might auto-magically generate an identifier. I'd
>>> recommend choosing a "large integer" representation instead of a
>>> string, however, since it will take less space to represent
>>> externally.  The GUID type is actually a fairly good choice here.
>>
>> Maybe it would make sense to use Steve Dewhurst's typeof()
>> technique. At least that could help reduce the number of user-supplied
>> identifiers needed.
>
> That may well be worth looking into, but I'm not familiar with the
> technique.  I know he generates unique integer ids (or at least, I think I
> know that), but will the generation produce consistent ids across
> application runs?  

Yes. It's a compile-time encoding. You have to register the UDTs, but
composite types such as T and T (*)(U,V) get unique type ids
automatically.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] String algorithm library

[Thorsten Ottosen]

- Original Message -
From: "Pavol Droba" <[EMAIL PROTECTED]>

> As there has been an interest I'd like to ask you if such a library should
become a part of boots
> in the future. I'd be happy to hear any opinions and suggestions.
I would always like prefer a library function to writing my own :-)

Ok, so a few comments:

> Trimming:
>
>Iterator trim_begin( Iterator InBegin, Iterator InEnd, const
std::locale& Loc=std::locale() )
>Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& ltrim_in( Seq& Input, const std::locale& Loc=std::locale() )
>Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
>Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )

I would find it more naturally to say

string s = ...;
trim( s );

than to use 'trim_in()'. I think the functions that return a new 'Seq'
should be the special cases, perhaps
just with an appended underscore? Or maybe we should rely on that there is
only one version of trim etc.
and we would do

string s2 = s;
trim( s2 )

instead of

string s2 = trim( s );

? I guess could be considered for the rest of the library and I think It
would simplify usage too, since it
destinguishes between queries and commands. The prototype would then just be

void trim( Seq& input, ... );

> Predicates:
>
>bool start_with(
> InputIterator Begin,  InputIterator End,
>   SubIterator SubBegin, SubIterator SubEnd,
>   BinaryPredicate Comp )
> bool start_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
Comp )
> bool end_with( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
Comp )
> bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
Comp )

I think the names should be 'starts_with' and 'ends_with', right?

BTW, much of the argument passing resembles what will be possible in the new
container algorithms I'm working on.
I guess you might just forward 'Seq.begin()' and 'Seq.end()'. In the
container
algorithms it will be possible to say

inta[] = ...;
pair p = 
vectorv = ...;

for_each( array, print()  );
for_each( p, print() );
for_each( v, print() );

What is relevant here is that the code below does not call .begin()/.end(),
but overloaded
freestanding begin() / end() functions. If your code should work with char
arrays or iterator ranges,
then you could benefit from the container algo. begin/end functions
approach. However, there is a big problem, namely that
the container algorithms don't work on eg. VC6/7.

regards

Thorsten Ottosen, AAU





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

Re: [boost] DocBook/XML Reference Documentation updates

[Ihsan Ali Al Darhi]

Hi...

Why don't you produce this explanation of how you will document Boost
library using XML and other stuffs in a single documentation?

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

Re: [boost] String algorithm library

[Thorsten Ottosen]

- Original Message -
From: "Pavol Droba" <[EMAIL PROTECTED]>

> bool contains( const Seq1& Input, const Seq2& Prefix, BinaryPredicate
Comp )

BTW, contains is one of the new proposed algorithms. It would be double work
to provide
it here.

regards

Thorsten Ottosen, AAU


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

RE: [boost] Named Template Parameters implementation

[Rozental, Gennadiy]

Unfortunately this implementation is using template template parameters and
partial specialization. I still could not find a time to write a proper
comments to this submission. I Will do soon. But If it does not bother it
pretty easy to use (easier then one adopted by me from iterator_adaptors for
smart_ptr implementation).

Gennadiy.

> -Original Message-
> From: Fernando Cacciola [mailto:fernando_cacciola@;hotmail.com]
> Sent: Friday, November 15, 2002 10:48 AM
> To: Boost mailing list
> Subject: Re: [boost] Named Template Parameters implementation
> 
> 
> 
> - Original Message -
> From: "Jaakko Jarvi" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Friday, November 15, 2002 12:18 PM
> Subject: Re: [boost] Named Template Parameters implementation
> 
> 
> >
> > On Fri, 15 Nov 2002, Fernando Cacciola
> > wrote:
> >
> > > As a final touch in the Numeric Conversion library I have 
> almost ready,
> I
> > > want to add it named template parameters for easier usage.
> > > Were can I borrow the State of the Art implementation of 
> this idiom
> from?
> >
> > Don't know about state of the art, but this library tries to do a
> > decent job:
> >
> > libs/named_template_parameters in boost sandbox.
> >
> 
> Yep, I've seen it... Looks pretty good.
> 
> I think I figured out how to use it.. But, do you have at 
> hand a sample
> usage of it?
> 
> And,
> 
> Can I borrow this header and include it in the submission 
> package for the
> Numeric Conversion library?
> Or do you prefer that we review it stand alone first?
> 
> 
> > /Jaakko
> 
> Thanks,
> 
> Fernando Cacciola
> 
> ___
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] String algorithm library

[Rozental, Gennadiy]

> Trimming:
> 
>Iterator trim_begin( Iterator InBegin, Iterator InEnd, 
> const std::locale& Loc=std::locale() )
>Seq ltrim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& ltrim_in( Seq& Input, const std::locale& Loc=std::locale() )
>Seq rtrim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& rtrim_in( Seq& Input, const std::locale& Loc=std::locale() )
>Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
>Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )

1. I would prefer explisit names: trim_left, trim_right,...
2. Where do you specify what to trim? What If I want to trim "<>"
3. why do we need not _in functions?
If you want it that bad you could do something like:
Seq& trim_copy( Seq& input, Seq& trim_func( Seq&, const std::locale& ) );

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

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Friday 15 November 2002 10:31 am, Gennaro Prota wrote:
> I don't see the reason for the inclusion of operator & either. However
> if really that reason doesn't exist it is *vry* strange that this
> wasn't noticed during discussions about library issue 69:
>
>  http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#69
>
> The rationale section for that defect says:
>
> There is no need to explicitly consider a user-defined operator&
> because elements must be copyconstructible (23.1
> [lib.container.requirements] para 3) and copyconstructible (20.1.3
> [lib.copyconstructible]) specifies requirements for operator&.
>
> How is it possible for it to pass unnoticed?
>
> Genny.

Most likely, those present either didn't think it was a problem or didn't feel 
strongly enough about the situation to speak up. There really aren't all that 
many good uses for overloading operator&, and it can be a bit dangerous, so I 
would expect some resistence in getting it removed from the CopyConstructible 
requirements. Come to think of it, if not for Lambda's overloading of 
operator&, I wouldn't really care about the issue :)

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

RE: [boost] MPL lambda

[Rozental, Gennadiy]

> -Original Message-
> From: Aleksey Gurtovoy [mailto:agurtovoy@;meta-comm.com]
> Sent: Friday, November 15, 2002 7:52 AM
> To: 'Boost mailing list'
> Subject: RE: [boost] MPL lambda
> 
> 
> Rozental, Gennadiy wrote:
> > I am having hard time grasping how this %#$% lambda facility 
> > is working. 
> 
> I hope you mean "what it does/how to use it" as opposite to 
> "how it does
> what it does" ;).

In fact it is second ;-)

> // numbered placeholders semantics
> plus<_1, int_c<5> > == bind,_1,int_c<5> >
> plus< int_c<5>,_1 > == bind,int_c<5>,_1 >
> plus< int_c<5>,_2 > == bind,int_c<5>,_2 >
> plus<_1,_2> == bind,_1,_2>
> plus<_2,_1> == bind,_2,_1>
> 
> logical_or< is_same<_1,int>, is_same<_1,long> >
> = bind< meta_fun2
> , bind< meta_fun2,_1,int >
> , bind< meta_fun2,_1,long >
> >
> 
> is_same< _1, add_pointer<_2> >
> == bind< meta_fun2
> , _1
> , bind< meta_fun1, _2 >
> >

It would help if you start with what meta_fun[n] are, cause they are not
covered in docs. Also if I understand correctly it require template template
parameters. How then it works for MSVC6.5?

> 
> // unnamed placeholder semantics
> plus< _,int_c<5> > == plus<_1, int_c<5> >
> plus< int_c<5>,_ > == plus< int_c<5>,_1 >
> ??? == plus< int_c<5>,_2 > // can't be built using 
> unnamed notation
> plus<_,_> == plus<_1,_2> 
> ??? == plus<_2,_1> 
> 
> logical_or< is_same<_,int>, is_same<_,long> >
> = logical_or< is_same<_1,int>, is_same<_1,long> >
> 
> is_same< _, add_pointer<_> > != is_same< _1, 
> add_pointer<_2> > // !!!
> is_same< _, add_pointer<_> >
> == bind< meta_fun2
> , _1
> , bind< meta_fun1, _1 > // !!!
> >
> 
So the _ placeholder is substituted with appropriated numbered one based on
position in expression. How did you managed to achieve this?

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

Re: [boost] DocBook/XML Reference Documentation updates

[Douglas Gregor]

On Saturday 02 February 2002 09:38 pm, Ihsan Ali Al Darhi wrote:
> Why don't you produce this explanation of how you will document Boost
> library using XML and other stuffs in a single documentation?

The input is a DocBook XML document with extended syntax that allows 
specification of C++ reference document. The extended syntax is similar to 
that of the DocBook elements for C or Java reference documentation, but 
suitable for C++ in all its, err, glory.

This DocBook XML + C++ XML document is fed through an XSLT stylesheet that 
formats the C++XML into normal DocBook XML. From there we can create 
distributed documentation in the normal DocBook way (I'm using the XSLT 
stylesheets for HTML, FO->PDF, and man page output).

The discussion of this started here, and somewhere in the pile is a full 
diagram showing how everything could work, starting with documentation 
extractors like Doxygen and Synopsis and ending with a number of end-user 
documentation formats:
  http://lists.boost.org/MailArchives/boost/msg38047.php

Doug

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

RE: [boost] DocBook/XML Reference Documentation updates

[Jeff Garland]

> The discussion of this started here, and somewhere in the pile is a full 
> diagram showing how everything could work, starting with documentation 
> extractors like Doxygen and Synopsis and ending with a number of end-user 
> documentation formats:

Captured on the Wiki @

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Documentation_Format

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

Re: [boost] Proposed Boost Assert -- once again

[Peter Dimov]

From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
> Peter Dimov writes:
> 
> > Making [Boost Assert] more suitable for application-level use may mean
> > that it becomes unacceptable for some Boost libraries.
> 
> Can you give me a for-instance?  I don't see the conflict.

No, I can't. This was a general statement.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Proposed Boost Assert -- once again

[Peter Dimov]

From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
> Peter Dimov write:
>
> > Throwing an exception from BOOST_ASSERT is undesired behavior. I don't
> > want it as a standard option.
>
> Except that, in the case I pointed out, it sometimes is desired behavior
> and the Right Thing(tm) to do.  One aborts an entire subcomputation /
> transaction rather than aborting the entire program.  I expect this to be
> the norm, not the exception (pardon the pun), for enterprise information
> systems.

I don't agree. Globally turning asserts into throws at the flip of a switch
is never the Right Thing(tm) to do. To handle this transition, the code
needs to be designed with it in mind. Otherwise the approach is, at best, a
hack: throw an exception and hope for the best.

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

Re: [boost] DocBook/XML Reference Documentation updates

[Douglas Gregor]

On Friday 15 November 2002 01:54 pm, Jeff Garland wrote:
> > The discussion of this started here, and somewhere in the pile is a full
> > diagram showing how everything could work, starting with documentation
> > extractors like Doxygen and Synopsis and ending with a number of end-user
> > documentation formats:
>
> Captured on the Wiki @
>
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Docume
>ntation_Format
>
> Jeff

Thanks Jeff! I really need to learn to use the wiki more...

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

Re: [boost] Named Template Parameters implementation

[Fernando Cacciola]

OK, I read the docs, followed the example and *tried* to use it in the
library.
Unfortunately, I received tons of mysterious compiler errors with BCC55;
apparently as a result of the usage of template template parameters in
ntp::as_named<>.

Gennadiy, I'm not sure if I understood what you said... do you have an
alternative implementation? If so, were?

Fernando Cacciola

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

[boost] Re: Proposed Boost Assert -- once again

[Bertolt Mildner]

> > > #include 
> > 
> > I don't follow what this is about.  The "handler," as I
> > understand it, is assertion_failed() declared below, so
> > why this header?
> 
> boost/current_function.hpp defines the
> BOOST_CURRENT_FUNCTION macro. 


BTW: CW also defines __PRETTY_FUNCTION__ (at least since 8.0)

diff -r1.3 current_function.hpp
30c30
< #if defined(__GNUC__)
---
> #if defined(__GNUC__) || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000))


-- 
Free Crypto Token - FCT
www.FreeCryptoToken.org



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

[boost] Re: Copy Constructible Concept

[Gennaro Prota]

On Fri, 15 Nov 2002 13:24:41 -0500, Douglas Gregor <[EMAIL PROTECTED]>
wrote:

>Most likely, those present either didn't think it was a problem or didn't feel 
>strongly enough about the situation to speak up. There really aren't all that 
>many good uses for overloading operator&, and it can be a bit dangerous, so I 
>would expect some resistence in getting it removed from the CopyConstructible 
>requirements. Come to think of it, if not for Lambda's overloading of 
>operator&, I wouldn't really care about the issue :)

Hmmm... if you proposed a resolution, could you please publish/post
the text of your report?

Genny.


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

Re: [boost] Re: Proposed Boost Assert -- once again

[Peter Dimov]

From: "Bertolt Mildner" <[EMAIL PROTECTED]>
>
> BTW: CW also defines __PRETTY_FUNCTION__ (at least since 8.0)
>
> diff -r1.3 current_function.hpp
> 30c30
> < #if defined(__GNUC__)
> ---
> > #if defined(__GNUC__) || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000))

Applied, thanks.

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

Re: [boost] Named Template Parameters implementation

[Jaakko Jarvi]

> OK, I read the docs, followed the example and *tried* to use it in the
> library.
> Unfortunately, I received tons of mysterious compiler errors with BCC55;
> apparently as a result of the usage of template template parameters in
> ntp::as_named<>.

as_named is needed if you allow an argument slot to accept both
unnamed and named template parameters.
You should be able to go around the need for template template 
parameters by 'expanding' as_name by hand:

instead of 

typename boost::ntp::as_named::type

write:

typename boost::mpl::if_c::value,
  T, Model_is >::type

Are there other things that cause trouble with your compiler?

/Jaakko



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

RE: [boost] Named Template Parameters implementation

[Rozental, Gennadiy]

This archive contains one header and test
http://groups.yahoo.com/group/boost/files/smart_pointers/Policy%20based%20sm
art_ptr/smart_ptr.zip

Here the message with description
http://aspn.activestate.com/ASPN/Mail/Message/1190858

Compile and work on MSVC6.5 and gcc.

But Jaakko version has it's own advantages. Maybe good portable version
somewhere in between. I will post with details later.

Gennadiy.

> -Original Message-
> From: Fernando Cacciola [mailto:fernando_cacciola@;hotmail.com]
> Sent: Friday, November 15, 2002 2:22 PM
> To: Boost mailing list
> Subject: Re: [boost] Named Template Parameters implementation
> 
> 
> OK, I read the docs, followed the example and *tried* to use it in the
> library.
> Unfortunately, I received tons of mysterious compiler errors 
> with BCC55;
> apparently as a result of the usage of template template parameters in
> ntp::as_named<>.
> 
> Gennadiy, I'm not sure if I understood what you said... do you have an
> alternative implementation? If so, were?
> 
> Fernando Cacciola
> 
> ___
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Friday 15 November 2002 02:42 pm, Gennaro Prota wrote:
> On Fri, 15 Nov 2002 13:24:41 -0500, Douglas Gregor <[EMAIL PROTECTED]>
>
> wrote:
> >Most likely, those present either didn't think it was a problem or didn't
> > feel strongly enough about the situation to speak up. There really aren't
> > all that many good uses for overloading operator&, and it can be a bit
> > dangerous, so I would expect some resistence in getting it removed from
> > the CopyConstructible requirements. Come to think of it, if not for
> > Lambda's overloading of operator&, I wouldn't really care about the issue
> > :)
>
> Hmmm... if you proposed a resolution, could you please publish/post
> the text of your report?
>
> Genny.

Strange that it wasn't in the Post-Santa Cruz mailing. Here's the text:


Defect report: CopyConstructible requirements too strict
Section: 20.1.3 [lib.copyconstructible]

The CopyConstructible requirements in Table 30 state that for an
object t of type T (where T is CopyConstructible), the expression &t
returns the address of t (with type T*). This requirement is overly
strict, in that it disallows types that overload operator& to not
return a value of type T*. This occurs, for instance, in the http://www.boost.org/lib/lambda";>Boost.Lambda library
function objects overload operator& to return the address of the
result of calling a function object. Example:

  std::vector u, v;
  int x;
  // ...
  std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);

_1 * x returns an unnamed function object with operator& overloaded,
therefore rendering the std::transform call ill-formed. However, most
standard library implementations will compile this code properly, and
the viability of such binder libraries is severely hindered by the
unnecessary restriction in the CopyConstructible requirements.

For reference, the address of an object can be retrieved without using
the address-of operator with the following function template:

  template  T* addressof(T& v)
  {
return reinterpret_cast(
 &const_cast(reinterpret_cast(v)));
  }

Note: this relates directly to library issue 350, which will need to
be reexamined if the CopyConstructible requirements change.

Proposed resolution:

Remove the last two rows of Table 30, eliminating the requirements
that &t and &u return the address of t and u, respectively.


Doug

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

[boost] bind, mem_fn, and private inheritance

[George A. Heintzelman]

Suppose I have the following:

class Base {
  void foo(int);
};

class Derived: private Base {
public:
  void bar();
};

void Derived::bar() {
  vector v;
  for_each(v.begin(), v.end(),
   boost::bind(&Base::foo,this,_1));
}

This is a reasonably common thing to want to do, except for the private 
inheritance part... It bombs because in the instantiation of bind, it 
knows this is a Derived *, and doesn't try to forcibly instantiate the 
version which takes a Base * (even though it knows that Base::foo is a 
member of Base). Then in operator() it is using a pointer to Derived to 
attempt to call a function on Base. That's no good.

I think it might be possible to fix this, but it's tricky. Just 
defining the partial specialization for Base * in boost::bind won't 
work because it'll find the exact template match instead. I think 
instead you have to define a partial specialization for all pointers in 
which you use the version that takes the Base *. Unfortunately that 
leads to an asymmetry for references, where I don't think you can get 
away with doing the simple partial specialization without yet more 
metacode. Probably doable but painful.

Anyway, it's not that hard to work around in the client code of course 
(a simple static_cast(this)), but I thought I would mention it 
as a test case if someone wants to improve the user-friendliness of 
boost::bind even further.

George Heintzelman
[EMAIL PROTECTED]


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

RE: [boost] Proposed Boost Assert -- once again

[Jon Kalb]

> -Original Message-
> From: Kevin S. Van Horn [mailto:Kevin.VanHorn@;ndsu.NoDak.edu] 
> Sent: Friday, November 15, 2002 9:00 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [boost] Proposed Boost Assert -- once again
> 
> 
> Peter Dimov write:
> 
> > Throwing an exception from BOOST_ASSERT is undesired 
> > behavior. I don't want it as a standard option.
> 
> Except that, in the case I pointed out, it sometimes is 
> desired behavior 
> and the Right Thing(tm) to do.  One aborts an entire subcomputation / 
> transaction rather than aborting the entire program.  I 
> expect this to be 
> the norm, not the exception (pardon the pun), for enterprise 
> information 
> systems.  Because it is a common, important case, it is 
> desirable that we 
> provide a standard solution for this case.  If you like, the 
> documentation 
> can make it clear exactly under which circumstances use of the 
> exception-throwing behavior is desirable, and when it is not.

In my opinion, and I think this is where Peter is coming from, if
throwing an exception is the right thing to do, then the situation is an
expected (if exceptional) case. In that situation, an assertion is not
appropriate.

In the situation that you outline above, it appears to me that you are
planning to use BOOST_ASSERT() in "shipping" (deployed?) code. If that
is your plan, you are not using BOOST_ASSERT() as an assertion, but as a
run-time check. There is certainly nothing wrong with runtime checks
that throw, but I think calling them "assertions" is inconsistent with
the traditional software engineering meaning of the word and a
disservice to others working with your code.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Proposed Boost Assert -- once again

[Kevin S. Van Horn]

David Abrahams writes:

>> I don't want to make a mountain out of a molehill, but I believe there
>> is a difference between the two:  is part of the C++ Standard,
>> and  is not.  [...]
>
> Nope. [...] C++ includes all of the 'C' headers.

OK.  Objection withdrawn.


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

Re: [boost] Re: Copy Constructible Concept

[Gennaro Prota]

--- Douglas Gregor <[EMAIL PROTECTED]> wrote:

[...]
> For reference, the address of an object can be retrieved without using
> the address-of operator with the following function template:
> 
>   template  T* addressof(T& v)
>   {
> return reinterpret_cast(
>  &const_cast(reinterpret_cast(v)));
>   }
> 
> Note: this relates directly to library issue 350, which will need to
> be reexamined if the CopyConstructible requirements change.
> 
> Proposed resolution:
> 
> Remove the last two rows of Table 30, eliminating the requirements
> that &t and &u return the address of t and u, respectively.

Thank you very much for your reply. The text confirmed what I suspected from
your previous words (suspect that is why I asked you to post the text itself),
i.e. that you prefer to drop any requirements on operator& instead of inventing
a separate concept (say "Addressable") for them. The problem I see in your
resolution is that AFAIK addressof() is not guaranteed to work by the standard.
Yes, it has an extremely high probability to do the right thing, but not a
guarantee. So I think either we find another portable way to take the address
or invent a new concept (which I like, though of course it requires more
changes to the standard)

Genny.

__
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Copy Constructible Concept

[David Abrahams]

Douglas Gregor <[EMAIL PROTECTED]> writes:

> On Friday 15 November 2002 02:42 pm, Gennaro Prota wrote:
>> On Fri, 15 Nov 2002 13:24:41 -0500, Douglas Gregor <[EMAIL PROTECTED]>
>>
>> wrote:
>> >Most likely, those present either didn't think it was a problem or didn't
>> > feel strongly enough about the situation to speak up. There really aren't
>> > all that many good uses for overloading operator&, and it can be a bit
>> > dangerous, so I would expect some resistence in getting it removed from
>> > the CopyConstructible requirements. Come to think of it, if not for
>> > Lambda's overloading of operator&, I wouldn't really care about the issue
>> > :)
>>
>> Hmmm... if you proposed a resolution, could you please publish/post
>> the text of your report?
>>
>> Genny.
>
> Strange that it wasn't in the Post-Santa Cruz mailing. Here's the text:
>
> 
> Defect report: CopyConstructible requirements too strict
> Section: 20.1.3 [lib.copyconstructible]
>
> The CopyConstructible requirements in Table 30 state that for an
> object t of type T (where T is CopyConstructible), the expression &t
> returns the address of t (with type T*). This requirement is overly
> strict, in that it disallows types that overload operator& to not
> return a value of type T*. This occurs, for instance, in the  href="http://www.boost.org/lib/lambda";>Boost.Lambda library
> function objects overload operator& to return the address of the
> result of calling a function object. Example:
>
>   std::vector u, v;
>   int x;
>   // ...
>   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
>
> _1 * x returns an unnamed function object with operator& overloaded,
> therefore rendering the std::transform call ill-formed. However, most
> standard library implementations will compile this code properly, and
> the viability of such binder libraries is severely hindered by the
> unnecessary restriction in the CopyConstructible requirements.
>
> For reference, the address of an object can be retrieved without using
> the address-of operator with the following function template:
>
>   template  T* addressof(T& v)
>   {
> return reinterpret_cast(
>  &const_cast(reinterpret_cast(v)));
>   }

Ouch! Did we really write that in the DR? Didn't we just have a long
argument in this forum about how the results of reinterpret_cast are
not portable?!

That should be:

 ...

Umm, actually I don't see a way to write that in a portable
manner. I'm afraid we just made another DR mistake. I don't think the
CopyConstructible requirements were to strict before the DR was
issued. I hope there's a way to take it back. Matt?

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Friday 15 November 2002 03:36 pm, Gennaro Prota wrote:
> of inventing a separate concept (say "Addressable") for them. The problem I
> see in your resolution is that AFAIK addressof() is not guaranteed to work
> by the standard. Yes, it has an extremely high probability to do the right
> thing, but not a guarantee.

You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets 
addressof() work:
  "That is, a reference cast reinterpret_cast(x) has the same effect as 
the conversion *reinterpret_cast(&x) with the builtin & and * operators."

(And that reinterpret casting T* -> U* -> T* preserves the original value).

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

Re: [boost] DocBook/XML Reference Documentation updates

[David Abrahams]

Douglas Gregor <[EMAIL PROTECTED]> writes:

> On Friday 15 November 2002 01:54 pm, Jeff Garland wrote:
>> > The discussion of this started here, and somewhere in the pile is a full
>> > diagram showing how everything could work, starting with documentation
>> > extractors like Doxygen and Synopsis and ending with a number of end-user
>> > documentation formats:
>>
>> Captured on the Wiki @
>>
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Docume
>>ntation_Format
>>
>> Jeff
>
> Thanks Jeff! I really need to learn to use the wiki more...

Yeah, I suggest that we try to do some more stuff there. I'll try to
get some links to Synopsis and ReST info going...

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

RE: [boost] Pool Iterators?

[scleary]

> -Original Message-
> From: Geoff Leyland [mailto:geoff.leyland@;epfl.ch]
> 
> Hi Steve,
> 
> Thanks for the reply.

And sorry for the delay on this reply! :)

> On Lundi, novembre 11, 2002, at 06:00 , [EMAIL PROTECTED] wrote:
> 
> > One possibility is to write an object type that sits between your 
> > object and
> > the pool allocator, which adds a single pointer to your object.  
> > Something
> > similar to what a doubly-linked list container would do 
> when rebinding 
> > its
> > Allocator.  This gives you the ability to iterate over 
> them, and also 
> > allows
> > fast insertion and deletion.
> 
> This pretty much what I've got.  There's an object that talks 
> to a the 
> pool, and remembers everything that I've allocated in a 
> vector (actually 
> a holey_vector).
> This was really slow for deleting something, because 
> searching through a 
> list of 2 pointers for the one you want is a waste of time.
> I solved that my sticking a back-pointer in the object 
> itself. This is a 
> sufficient solution, but I think it lacks elegance compared to a 
> possible pool_iterator, but, if you think it's the best idea, I'll go 
> that way.
> 
> One of the reasons I like the pool_iterator is that I store 
> the pointers 
> themselves in a vector with "holes".  This makes insertion 
> and deletion 
> in the vector very fast, and you can iterate through it very 
> quickly.  
> The free list is a map of free indexes, which means it's easy to work 
> out as you walk through the list which elements are free, and 
> also, that 
> any new allocations into free space are at the bottom of the 
> list, so, 
> with a bit of luck, you can cut the end off a shrinking list.
> I was pretty much of the opinion that this was just a cheap and nasty 
> substitute for a real pool allocator (it's what I was using before I 
> used pool), not in the least because when the vector resizes 
> the whole 
> thing moves.

I think I have been too lacking in sleep lately, and I cannot wrap my brain
around what you're describing.  But it seems to me that this requires
additional space overhead for a pool, so it's not something that I would
want to see in the generic pool<>.  However, if it's something you think
would be usable to others and can be built on top of the generic pool<>, I'd
be willing to accept an interface built on top of pool.

> There's stuff in the code and comments about an "ordered" 
> free list.  If 
> you can excuse my ignorance, does this mean that it's potentially 
> possible to walk through the pool's storage at the same time 
> as walking 
> through the ordered free list and find out fairly cheaply 
> which blocks 
> are free?

Yup.  A pool can be ordered or not, depending on how it is used.  If it is
ordered, then you can walk through the storage and free list at the same
time.  Take a look at release_memory() in pool.hpp, which does exactly that
-- it looks for allocated sections of storage that are completely free and
releases them back to the OS.

> > A similar approach, if you're willing to more seriously 
> change the code 
> > that
> > allocates/deallocates the objects, is to keep a 
> doubly-linked list of
> > pointers to the allocated objects.  But then reference the objects
> > indirectly through iterators of that list.  If you 
> reference them in 
> > this
> > way, then deletion should be fast.
> 
> That's not a bad idea.  The easiest would be to just stick 
> next and prev 
> pointers in the objects themselves.  But even so, if 
> pool_iterators were 
> possible in a generic way, everyone would benefit, and my code would 
> "just work".

I think a generic wrapper on top of the generic pool would be the best
approach.  That would enable those who do not need the iterative
functionality to not pay the price of it, but also supply that functionality
for those users who need it.

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

Re: [boost] DocBook/XML Reference Documentation updates

[David Abrahams]

Douglas Gregor <[EMAIL PROTECTED]> writes:

> On Friday 15 November 2002 01:54 pm, Jeff Garland wrote:
>> > The discussion of this started here, and somewhere in the pile is a full
>> > diagram showing how everything could work, starting with documentation
>> > extractors like Doxygen and Synopsis and ending with a number of end-user
>> > documentation formats:
>>
>> Captured on the Wiki @
>>
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Docume
>>ntation_Format
>>
>> Jeff
>
> Thanks Jeff! I really need to learn to use the wiki more...

I just requested that Sourceforge set up
[EMAIL PROTECTED], which will be on-line within 24
hours. Hopefully that will allow some people who'd like to participate
to regulate the inbox flood more effectively ;-)

I'll let you all know when it's active.

-Dave

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Friday 15 November 2002 03:45 pm, Douglas Gregor wrote:
> On Friday 15 November 2002 03:36 pm, Gennaro Prota wrote:
> > of inventing a separate concept (say "Addressable") for them. The problem
> > I see in your resolution is that AFAIK addressof() is not guaranteed to
> > work by the standard. Yes, it has an extremely high probability to do the
> > right thing, but not a guarantee.
>
> You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets
> addressof() work:
>   "That is, a reference cast reinterpret_cast(x) has the same effect as
> the conversion *reinterpret_cast(&x) with the builtin & and *
> operators."
>
> (And that reinterpret casting T* -> U* -> T* preserves the original value).
>
>   Doug

Just to spell it out in agonizing detail, so we can look for any holes in my 
logic:

  template  T* addressof(T& v)
  {
return reinterpret_cast(
 &const_cast(reinterpret_cast(v)));
  }

By 5.2.10/10, "reinterpret_cast(v)" is equivalent to 
"*reinterpret_cast(&v)" with the built-in operators & 
and *.

Substitute this into the original expression:

  reinterpret_cast(
 &const_cast(&*reinterpret_cast(&v)));

The const/volatile qualifiers don't matter at all in reinterpret_cast or 
const_cast and the object is guaranteed to be the same object through the 
const_cast (5.2.10/7 and 5.2.11/3, respectively). Now we just have the case 
where we're reinterpret_casting T*->char*->T*, and that's covered by 
5.2.10/7.

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

Re: [boost] Re: Copy Constructible Concept

[David Abrahams]

Douglas Gregor <[EMAIL PROTECTED]> writes:

> On Friday 15 November 2002 03:36 pm, Gennaro Prota wrote:
>> of inventing a separate concept (say "Addressable") for them. The problem I
>> see in your resolution is that AFAIK addressof() is not guaranteed to work
>> by the standard. Yes, it has an extremely high probability to do the right
>> thing, but not a guarantee.
>
> You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets 
> addressof() work:
>   "That is, a reference cast reinterpret_cast(x) has the same effect as 
> the conversion *reinterpret_cast(&x) with the builtin & and * operators."
>
> (And that reinterpret casting T* -> U* -> T* preserves the original value).

But you're not doing that. You're doing a reinterpret_cast T& -> U
cv&, then taking the address, and reinterpret_casting to T*. Is that
really covered by the standard?

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

Re: [boost] Re: Copy Constructible Concept

[Gennaro Prota]

--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> On Friday 15 November 2002 03:36 pm, Gennaro Prota wrote:
> > of inventing a separate concept (say "Addressable") for them. The problem I
> > see in your resolution is that AFAIK addressof() is not guaranteed to work
> > by the standard. Yes, it has an extremely high probability to do the right
> > thing, but not a guarantee.
> 
> You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets 
> addressof() work:
>   "That is, a reference cast reinterpret_cast(x) has the same effect as 
> the conversion *reinterpret_cast(&x) with the builtin & and * operators."
> 
> (And that reinterpret casting T* -> U* -> T* preserves the original value).

Yes, I do know that paragraph. I think it needs some modification if one wants
to make clear that the above is allowed. Basically when I read the standard I
take a conservative approach, i.e. if there's the slightest doubt that my
situation is not what the text guarantees to work I consider myself in an
undefined case. Now, let me say that there's an explicit contradiction (as
usual in such scenarios where a "special" case is assumed to be specified
separately) between 5.2.10/10 and 5.2.10/7, because the latter says that in

  reinterpret_cast(&x)

you can only cast back the result to the source type, whereas 5.2.10/10 defines
the reference-cast in terms of pointer-cast and says it's ok to *dereference*
the resulting value. However the real issue is that we have first

  T -> cv char& -> char &

and then

  char * -> T*

The latter is a reinterpret_cast from an rvalue of type char*, so except that I
can cast it back to a char* the result is unspecified. The problem exists
because the definitions are (correctly IMHO) given in terms of "expressions"
(lvalue/rvalue) not of objects, and thus from the perspective of the last cast
you "miss" the fact that actually you are dealing with the address of a T: the
expression has still type char*, no matter what the type of the object actually
is.

In short, I agree with you that probably the intent is for it to work. But I
think that should be clarified.

Genny.

__
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Copy Constructible Concept

[Peter Dimov]

From: "Douglas Gregor" <[EMAIL PROTECTED]>
>
> Just to spell it out in agonizing detail, so we can look for any holes in
my
> logic:
>
>   template  T* addressof(T& v)
>   {
> return reinterpret_cast(
>  &const_cast(reinterpret_cast(v)));
>   }

The only hole is that the above doesn't work for function types, but you
probably know that. :-)

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

[boost] Re: Copy Constructible Concept

[Gennaro Prota]

On Fri, 15 Nov 2002 16:05:05 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:

>Douglas Gregor <[EMAIL PROTECTED]> writes:
>> You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets 
>> addressof() work:
>>   "That is, a reference cast reinterpret_cast(x) has the same effect as 
>> the conversion *reinterpret_cast(&x) with the builtin & and * operators."
>>
>> (And that reinterpret casting T* -> U* -> T* preserves the original value).
>
>But you're not doing that. You're doing a reinterpret_cast T& -> U
>cv&, then taking the address, and reinterpret_casting to T*. Is that
>really covered by the standard?

Who knows? When I encounter these sorts of situations I dream a
standard where propositions can be demonstrated like in mathematics or
counter-examples provided. Don't you?


Genny.


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

Re: [boost] DocBook/XML Reference Documentation updates

[David Abrahams]

David Abrahams <[EMAIL PROTECTED]> writes:

> Douglas Gregor <[EMAIL PROTECTED]> writes:
>
>> On Friday 15 November 2002 01:54 pm, Jeff Garland wrote:
>>> > The discussion of this started here, and somewhere in the pile is a full
>>> > diagram showing how everything could work, starting with documentation
>>> > extractors like Doxygen and Synopsis and ending with a number of end-user
>>> > documentation formats:
>>>
>>> Captured on the Wiki @
>>>
>>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Docume
>>>ntation_Format
>>>
>>> Jeff
>>
>> Thanks Jeff! I really need to learn to use the wiki more...
>
> I just requested that Sourceforge set up
> [EMAIL PROTECTED], which will be on-line within 24
> hours. Hopefully that will allow some people who'd like to participate
> to regulate the inbox flood more effectively ;-)
>
> I'll let you all know when it's active.

Done:
https://lists.sourceforge.net/lists/listinfo/boost-docs

Let's move the discussion there.

-Dave

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

[boost] Re: Serialization Submission version 6

[Alberto Barbati]

Vladimir Prus wrote:

Robert Ramey wrote:

Now I remember why I included this.

Suppose that an archive is created where the default local is a 
spanish speaking country where the number 123 thousand is written

123.000

The archive is sent to another country where the default locale is an 
english speaking country where the string

123.000

means 123
That's why I set the local to classic.

I'm well aware of this issue. See below.


is it a good idea to change stream locale without user's consent. Maybe,
archive should create *their own* (i/o)stream, sharing streambuffer with
the stream the user has passed, and with appropriately modified locale?


In my opinion it the archive should not change the stream locale without 
the programmer's consent. The main reason for this is that she may 
indeed want to use her own locale, for example to allow Unicode output.

Ovverriding only num_put/num_get (and why not ctype also?) is not a nice 
solution, in my opinion, it's just a hack. Moreover, I can imagine a 
brave programmer that is aware that her serialized data will not be read 
by any other application except hers and decides to have the text output 
to follow her native language conventions.

In the end, between the two possibilities:

1) override the locale (entirely or partially), reducing programmer's 
freedom of customizing the output but guaranteeing a perfect portable 
output;

2) not override the locale, leaving to the programmer the complete 
responsiblity to set the right one that satisfies her specific 
requirements, with the risk that she messes things up;

I vote without doubt for number 2.

To be paranoid, on output we could write in each archive a magic number 
like 12345.678, on input we try to read it and if it doesn't match the 
magic number, we issue an error. I know that this hack won't catch 100% 
of the problems, but it will catch most of them and is not less safe 
than writing the sizeof() of the basic types as we are currently doing.

Alberto Barbati



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

Re: [boost] Re: Copy Constructible Concept

[David Abrahams]

Gennaro Prota <[EMAIL PROTECTED]> writes:

> On Fri, 15 Nov 2002 16:05:05 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Douglas Gregor <[EMAIL PROTECTED]> writes:
>>> You'll have to back that up with some standardese. AFAICT, 5.2.10/10 lets 
>>> addressof() work:
>>>   "That is, a reference cast reinterpret_cast(x) has the same effect as 
>>> the conversion *reinterpret_cast(&x) with the builtin & and * operators."
>>>
>>> (And that reinterpret casting T* -> U* -> T* preserves the original value).
>>
>>But you're not doing that. You're doing a reinterpret_cast T& -> U
>>cv&, then taking the address, and reinterpret_casting to T*. Is that
>>really covered by the standard?
>
> Who knows? When I encounter these sorts of situations I dream a
> standard where propositions can be demonstrated like in mathematics or
> counter-examples provided. Don't you?

Yeah, but then I start dreaming of programs which can read my
questions in English and produce a mathematical proof for me .

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

[boost] Re: Serialization Submission version 6

[Alberto Barbati]

Robert Ramey wrote:

I believe I have found the an acceptable resolution to the "registration" cunundrum.


(note: I consider this "registration" topic is a different issue from my 
 registry class proposal. This one relates to "identification" of user 
classes, while mine is just an issue of factorizing responsibilities 
among library classes)

I agree that this solution of the "identification" issue is quite right 
and would be very beneficial to the overall usefulness of the library. 
Bravo to Robert and Vladimir.

I conjure up something like (pseudo code):

register_cross_program_class_identifier(const char *id="T")


The perfect place for this function could be as a method of my registry 
class, don't you think? ;)

Alberto Barbati



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

[boost] Re: Serialization Submission version 6

[Alberto Barbati]

Vahan Margaryan wrote:

Eric Woodruff wrote:

type_info is not portable in the slightest.

I realize that. I just pointed out that it's not so convenient to have
user-supplied string ids because of the template classes.


As pointed out by Robert, the user-supplied string id could be made 
optional. For the lazy user we might imagine a default value obtained in 
some programmatic way, for example a possibly pre-processed 
type_info::name().

Alberto Barbati



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

Re: [boost] Re: Copy Constructible Concept

[Gennaro Prota]

--- David Abrahams <[EMAIL PROTECTED]> wrote:
> Gennaro Prota <[EMAIL PROTECTED]> writes:

> > Who knows? When I encounter these sorts of situations I dream a
> > standard where propositions can be demonstrated like in mathematics or
> > counter-examples provided. Don't you?
> 
> Yeah, but then I start dreaming of programs which can read my
> questions in English and produce a mathematical proof for me .

By no means! I can never dream of a program that steals all my fun :-)


__
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: String algorithm library

[Alberto Barbati]

Rozental, Gennadiy wrote:

Seq& trim_copy( Seq& input, Seq& trim_func( Seq&, const std::locale& ) );


In my opinion all algorithms without suffix should perform in-place 
operations, while the ones that make copies should have suffix "_copy". 
That would be more intuitive and also more consistent with the STL.

Alberto Barbati



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

Re: [boost] Re: Copy Constructible Concept

[Terje Slettebø]

>From: "Gennaro Prota" <[EMAIL PROTECTED]>

> On Fri, 15 Nov 2002 16:05:05 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
> >Douglas Gregor <[EMAIL PROTECTED]> writes:
> >> You'll have to back that up with some standardese. AFAICT, 5.2.10/10
lets
> >> addressof() work:
> >>   "That is, a reference cast reinterpret_cast(x) has the same
effect as
> >> the conversion *reinterpret_cast(&x) with the builtin & and *
operators."
> >>
> >> (And that reinterpret casting T* -> U* -> T* preserves the original
value).
> >
> >But you're not doing that. You're doing a reinterpret_cast T& -> U
> >cv&, then taking the address, and reinterpret_casting to T*. Is that
> >really covered by the standard?
>
> Who knows? When I encounter these sorts of situations I dream a
> standard where propositions can be demonstrated like in mathematics or
> counter-examples provided. Don't you?

You're not the only one. Bjarne Stroustrup says the same in "The Design and
Evolution of C++" (p. 103):

--- Start quote ---

Tools for Language Design

Theory and tools more advanced than a blackboard have not been given much
space in the description of the design and evolution of C++. I tried to use
YACC (an LALR(1) parser generator) for the grammar work, and was defeated by
C's syntax. I looked at denotional semantics, but was again defeated by
quirks in C. Ravi Sethi had looked into that problem and found that he
couldn't express the C semantics that way.

The main problem was the irregularity of C and a number of
implementation-dependent and undefined aspects of a C implementation. Much
later, the ANSI/ISO C++ committee had a stream of formal definition experts
explain their techniques and tools and give their opinions of the extent to
which a genuine formal approach to the definition of C++ would help us in
the standards effort. I also looked at the formal specifications of ML and
Modula-2 to see if a formal approach was likely to lead to a shorter and
more elegant description than traditional English text would. I don't think
that such a description of C++ would be less likely to be misinterpreted by
implementers and expert users. My conclusion is that a formal definition of
a language that is not designed together with a formal definition method is
beyond the ability of all but a handful of experts in formal definition.
This confirms my conclusion at the time.

--- End quote ---

Another comment, regarding using Spirit for parsing C++ that has been
discussed here (D&E, p. 69):

"To this day, Cfront has a YACC parser supplemented by much lexical trickery
relying on recursive descent techniques. On the other hand, it _is_ possible
to write an efficient and reasonably nice recursive descent parser for C++.
Several modern C++ compilers use recursive descent."


Regards,

Terje

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

Re: [boost] Re: Copy Constructible Concept

[Terje Slettebø]

>From: "Gennaro Prota" <[EMAIL PROTECTED]>

> --- David Abrahams <[EMAIL PROTECTED]> wrote:
> > Gennaro Prota <[EMAIL PROTECTED]> writes:
>
> > > Who knows? When I encounter these sorts of situations I dream a
> > > standard where propositions can be demonstrated like in mathematics or
> > > counter-examples provided. Don't you?
> >
> > Yeah, but then I start dreaming of programs which can read my
> > questions in English and produce a mathematical proof for me .
>
> By no means! I can never dream of a program that steals all my fun :-)

Not at all. Someone has to make the system that is capable of this. :)

"I would rather write programs to help me write programs than write
programs." - Dick Sites

(Quoted in "Generative Programming")


Regards,

Terje

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

Re: [boost] Named Template Parameters implementation

[Fernando Cacciola]

- Original Message -
From: "Jaakko Jarvi" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Friday, November 15, 2002 4:50 PM
Subject: Re: [boost] Named Template Parameters implementation


> > OK, I read the docs, followed the example and *tried* to use it in the
> > library.
> > Unfortunately, I received tons of mysterious compiler errors with BCC55;
> > apparently as a result of the usage of template template parameters in
> > ntp::as_named<>.
>
> as_named is needed if you allow an argument slot to accept both
> unnamed and named template parameters.
> You should be able to go around the need for template template
> parameters by 'expanding' as_name by hand:
>
> instead of
>
> typename boost::ntp::as_named::type
>
> write:
>
> typename boost::mpl::if_c::value,
>   T, Model_is >::type
>
> Are there other things that cause trouble with your compiler?
>
Yes, unfortunately...

I have expaned is_named all the way as follow:

typedef boost::ntp::detail::is_named_parameter Model_IsNamed ;
typedef boost::ntp::detail::is_named_parameter Color_IsNamed ;

typedef Model_is NamedModel ;
typedef Color_is NamedColor ;

typedef typename boost::mpl::if_::type
ModelP ;
typedef typename boost::mpl::if_::type
ColorP ;

typedef boost::tuple argument_tuple;


But then  I get:

typedef typename features::Model Model ;

---> Member is ambiguous:  Model_is::Model and
'default_car_fetures::Model'

If I change

  typedef boost::tuple argument_tuple;

to this:

  typedef boost::tuple< Model_is, Color_is,Seats,Transmission>
argument_tuple;

So to fix the 'make it Named' part

I get the same error.

Perhaps BCC is getting confused when the tuple elements are *local*
instances of the Named parameters.
Because after all, if I remove the 'Make sure is Named' part and let the
test use only truly named parameters it works.
That is, if the local template parameter Model is already 'Model_is' it
works.

Any ideas?

BTW: I get the same errors if I skip the depedent-feature part.
That is, if I use this directly:

  typedef boost::ntp::named_parameter_extractor features;





(PS: I'm leaving now, so I won't get back to this until Monday...)

> /Jaakko
>

Fernando Cacciola

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

[boost] Re: Serialization Submission version 6

[Alberto Barbati]

Robert Ramey wrote:
>

register_cross_program_class_identifier(const char *id="T")

>

An alternative could be to use register_type<> as it is, but augment the 
serialization traits class to provide a

const char* serialization::get_cross_program_class_identifier();

This solution has the advantage that the identifier string can be 
physically located near the load/save/version functions (which are 
usually near the class itself).

Alberto Barbati



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

[boost] high order type traits and MPL

[Gennadiy Rozental]

Hi,

Does anybody know how to implement type traits that will allow me to check
whether argument type T is instance od template A. Particulaly I am
interested in mpl sequences. I.e.:

is_instance_of::value

This syntax presume template template  parameter. I would prefer MSVC6
compartible way of course.

Gennadiy.





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

Re: [boost] high order type traits and MPL

[Jaakko Jarvi]

On Fri, 15 Nov 2002, Gennadiy Rozental wrote:

> Hi,
> 
> Does anybody know how to implement type traits that will allow me to check
> whether argument type T is instance od template A. Particulaly I am
> interested in mpl sequences. I.e.:
> 
> is_instance_of::value

Check out boost/lambda/detail/is_instance_of.hpp

/Jaakko


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

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Friday 15 November 2002 04:45 pm, Gennaro Prota wrote:
> Now, let me say that there's an explicit
> contradiction (as usual in such scenarios where a "special" case is assumed
> to be specified separately) between 5.2.10/10 and 5.2.10/7, because the
> latter says that in
>
>   reinterpret_cast(&x)
>
> you can only cast back the result to the source type, whereas 5.2.10/10
> defines the reference-cast in terms of pointer-cast and says it's ok to
> *dereference* the resulting value.

I don't see the contradiction here. 5.2.10/7 says that you can cast from a T 
pointer to a U pointer and back to a T pointer and get the original pointer 
back. 5.2.10/10 says that reinterpret_cast does the same for references (by 
specifying the semantics of reinterpret_cast on references in terms of 
reinterpret_cast on pointers). The dereference (and address-of, for that 
matter) operators are only there to perform the pointer/reference conversions 
to that the semantic equivalent can be specified.

If there's a contradiction between these two paragraphs, then there has to be 
some piece of code that can be interpreted in two different ways. Do we have 
such an example?

> However the real issue is that we have
> first
>
>   T -> cv char& -> char &
>
> and then
>
>   char * -> T*
>
> The latter is a reinterpret_cast from an rvalue of type char*, so except
> that I can cast it back to a char* the result is unspecified.

By 5.2.10/10, the first part of that is semantically equivalent to:

  T* -> cv char* ->char*

> In short, I agree with you that probably the intent is for it to work. But
> I think that should be clarified.
>
> Genny.

I've given probably the closest thing to a proof that one can get without 
having a formal specification. It uses only semantic equivalences given in 
the three paragraphs it cites. Is there a problem with it?

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

[boost] tuples doc problem

[David Abrahams]

The advanced features page doesn't say which namespace classes such as
boost::tuples::null_type reside in, AFAICT. If I just missed it, it
needs to be clarified.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

[boost] Re Serialization - locale

[Robert Ramey]

Gentlemen,

Those interested in locale for text archives:

How does this strike you?

text_iarchive(Stream  &_is) : 
is(_is)
{
// archives always use classic locale
#ifndef BOOST_NO_STD_LOCALE
plocale = is.imbue(std::locale::classic());
#endif
init();
}
~text_iarchive(){
#ifndef BOOST_NO_STD_LOCALE
is.imbue(plocale);
#endif
}

Another observation:

I note that my test.cpp program includes wchar_t member variables initialized to 
values in excess of 256.
The system doesn't seem to lose any informaton in storing/loading to a stream with 
classic locale.

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

[boost] Re: high order type traits and MPL

[Gennadiy Rozental]

> > Hi,
> >
> > Does anybody know how to implement type traits that will allow me to
check
> > whether argument type T is instance od template A. Particularly I am
> > interested in mpl sequences. I.e.:
> >
> > is_instance_of::value
>
> Check out boost/lambda/detail/is_instance_of.hpp
>
> /Jaakko

1. Could we make it an "official" type trait?
2. Could we make if work with no template template support?
I was thinking about:
is_instance_of >::value
But I do not understand how mpl::lambda is working yet, so it could be
complete nonsense.
3. Why there is no namely is_instance_of version without number of template
parameters explicitly specified.
Could not you deduce it automatically?
4. Why it is limited only to 4 template parameters?

Gennadiy.




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

Re: [boost] Re: Copy Constructible Concept

[David Abrahams]

Douglas Gregor <[EMAIL PROTECTED]> writes:

> I've given probably the closest thing to a proof that one can get without 
> having a formal specification. It uses only semantic equivalences given in 
> the three paragraphs it cites. Is there a problem with it?

FWIW, I'm satisfied.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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

[boost] Re: Proposed Boost Assert -- once again

[Eric Woodruff]

In my opinion, assertions indicate enfrorcement of pre/post conditions, that
are separate from the algorithmic logic of a function. What happens from the
result of the assertion, an exception or an abort is a separate issue.

Consider (if assert takes a boost::function0):

assert (!harddrive.isFragmented (), boost::bind (&HardDrive::defrag,
&harddrive));

In this case, it there is a simple remedy to the failed pre-condition. The
alternative is: assert (!harddrive.isFragmented (), std::abort);




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

RE: [boost] Re: Proposed Boost Assert -- once again

[Glen Knowles]

Title: RE: [boost] Re: Proposed Boost Assert -- once again





> From: Eric Woodruff [mailto:[EMAIL PROTECTED]]
>
> In my opinion, assertions indicate enfrorcement of pre/post conditions, that
> are separate from the algorithmic logic of a function. What happens from the
> result of the assertion, an exception or an abort is a separate issue.
>
> Consider (if assert takes a boost::function0):
>
> assert (!harddrive.isFragmented (), boost::bind (&HardDrive::defrag,
> &harddrive));
>
> In this case, it there is a simple remedy to the failed pre-condition. The
> alternative is: assert (!harddrive.isFragmented (), std::abort);


In the first case you're not talking about a failed precondition, because 
the logic (of which the assert is a part) is designed to handle both cases. 
I don't like the idea of using assert in that way at all and would strongly 
encourage it be replaced with:


if (!harddrive.isFragmented()) harddrive.defrag();


I really agree with Peter here, assert shouldn't have a canned option for
throwing. When you really need logic errors to throw you have to put a 
non-trivial supporting infrastructure in place and very likely a more
complex protocol then a simple throw. I've spent the last year working on
a server with a "can't stop" requirement and the objects it throws 
may include information about the subsystem that's been affected and the 
scope of the problem.


Glen