Re: [boost] Re: Patch for smart_ptr with Sun CC 5.3 toavoidcompilerinternal error

[Baptiste Lepilleur]

The compiler complains about an ambiguity between operator int() and
operator bool() when we try to use bool conversion. Removing the operator
int() declaration solved the ambiguity.

The good news is that work-around is no longer necessary starting with Sun
CC 5.4 (0x540).

On another hand, we still have some strange link issues. The linker
complains some symbols related to checked_deleleter not being defined. We
managed to remove some of those by adding explict template instanation in
shared_ptr default constructor (sizeof(checked_deleter);), but some
remains.

As anybody run into that ? This does not even happen on a determinist basis
(80% of the shared_ptr types work well).

Baptiste.

- Original Message - 
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, May 21, 2003 11:47 AM
Subject: Re: [boost] Re: Patch for smart_ptr with Sun CC 5.3 to
avoidcompilerinternal error


> Baptiste Lepilleur wrote:
> >> Please ignore the previous patch, it was buggy (operator bool was
> >> implemented in term of operator !). This is fixed & tested now.
>
> I've already implemented something along these lines, please test the CVS
> version and report any problems that you find.
>
> ___
> 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: Formal Review: Command Line & Config library

[Pavol Droba]

Hi

On Fri, May 23, 2003 at 09:15:58AM +0400, Vladimir Prus wrote:

[snip]
 
> I'll keep this in mind. In fact, I plan to convert all the documentation
> into BoostBook is the library is accepted. The Doxygen is very nice --- in
> fact, it helps very much to keep everything documented. But I found it
> rather limiting for writing various "overview" pages. Hope new
> documentation will be better.

Great.


> > * Validation
> >
> >Library allows to supports validation and parsing of option parameters,
> >but I thinks it is rather limited. It is possible to define
> >user-specific behaviour, but it would be helpful, if some common
> >formats would be suported.
> > 
> >For instance:
> >   * Various integer types ( not just int ) with boundary checking.
> > Something like
> >paramter( "count", 1, 4, &count ) // 1-Min and 4-Max
> >value
> 
> It's funny that the very first prototype version had this facility. In
> surely can be added to the current version if there's such need.
> 
>

I like the idea proposed by Tanton. po::parameter should have a validation
predicate as an argument. 
A reasonable set of arguments can be provided by library, and the user can always
provide a specific ones.

 
> >   * Format specification and checking for string. Regex specification
> >   of something like scanf would be nice.
> > This can be useful for example to check if the parameter is a
> > filename.
> 
> Could you clarify a bit how scanf-like specification can work? You mean it
> can be used to specify syntax? 
> 

I mean something like "%02.4f" or something like that... it is just an idea. If there
would be a validation predicate as an argument, regex library can be used to define
regex predicate which would cover most of the cases.


> > * Environment & Others
> > 
> >The library tries to unify the access to program options from command
> >line and from ini files. This is very nice feature because it is
> >removing the need for doing generaly the same thing twice. It would be
> >nice if some other sources of paramers could be incorporated as well.
> >Particulary the enviromnmet is often used to exchange arguments. Given
> >the fact that it consist of a set of pairs "variable=value" it is very
> >similar to the ini file and so it souldn't be hard to implement.
> 
> Thanks for the suggestion! It's quite right.
>  
> >For windows platform the registry comes to play as another source of
> >options.
> 
> Yep, that source was considered as alternative from the very start. I've
> seen some project start with a command line, then add config files and then
> need registry on Windows. Registry is not yet supported because I wanted to
> find out if there's support to the idea of uniform access to all
> configuration means.

I definitely like the idea of the uniform access. It would be only welcome if the 
library
can cover more sources of options.

Pavol

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

Re: [boost] Re: Formal Review: Command Line & Config library

[Baptiste Lepilleur]

- Original Message - 
From: "Rob Stewart" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2003 8:15 PM
Subject: Re: [boost] Re: Formal Review: Command Line & Config library


> From: "James Curran" <[EMAIL PROTECTED]>
> > Chuck Messenger wrote:
> > >> * add_options() should use references rather than pointers
> >
> > > "Pointer for return value" is C semantics.  In C++,
> > > pointers denote optional values.  Non-const references are for return
> > > values.
> >
> > I disagree *strongly*.   In C and C++, the address-of syntax clearly
> > indicates that this is a value that will be changed.  Your suggestion of
> > using a non-const reference would require me to check the header file to
> > find the signature of _every_single_F#$^%ing_function to figure out
which
> > parameters are changed and which one's aren't.  (particularly in the
case of
>
> Disagree strongly all you want, but I only use pointers to
> indicate optional arguments and to pass references (general
> meaning of the word) to objects that are expected to outlive the
> object to which they are given (usually in the ctor).  In the
> former case, the argument may be null so I check for that case.
> In the latter, I often use RCSPs, but not always.
>
> I don't use non-const reference parameters often (and when I do
> they are always the first argument(s)).  I find they work
> intuitively.  You see, such functions always indicate, by their
> very name, that they are providing a value, so the name quite
> reasonably documents the output parameter.
>
> Using pointers in this context would be counterintuitive to me.
>
> Ultimately, someone will be disappointed.

Allow me to provide a few arguments in favor of using non-const reference
instead of pointer, that may be will help reaching a conclusion (when to use
pointer and reference is mainly a matter of style & guideline, therefore
leading to 'endless' discussion).

Boost defines some guidelines. Among those are references to Scott Meyer
'Effective C++' series. While no requirement is made to follow the
guidelines contained in the book the suggestion is made. Scott Meyer
provides some guidelines on when to use reference and pointer. In the
current case, it would sum up to 'use pointer when the parameter can be
optional, in which case a null pointer will be passed'. As a user of boost
library, I would expect that guideline to be followed (to my knowledge, this
is the case for most (all ?) existing boost libraries).

Also, the add_options() usage as some similarity with Boost.Tuple tie()
function, which use reference. Renaming may help if you fell that the
current name isn't clear enough (tie_options ?)

Regards,
Baptiste.

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

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

Re: [boost] proposal for efficient geom. vector class

[jvd]

I've read many comments and so there're some of my thoughts.

uBLAS is a very nice library but I'm not sure that conceptually geometrical
primitives would fit in its context very well. Looking forwardly, there
would be not only hom. vectors and matrices but other geom. primitives as
well, e.g., segments, perhaps convex_planar_polygons, planes, etc. Having
planes and other things mentioned above - would be nice to have
Sutherland-Hodg. clipping algorithm, etc. These things can be very useful in
many contexts - not only in specific video processing routines (as some
mistakingly pointed out).

Also strong emphasis is on STL/boost compliance and perhaps learning curve
(besides, I've missed vector upgrading/degrading in many libraries - in
other words - derivation and its prime(?) (English is not my mother
language, after all) vectors).

I don't know where to upload this piece of code currently so I beg you
pardon for sending an attachment. BTW, it is by no means a final
implementation of things I've just written above. It's just an initial piece
of code - constructive comments, etc. would be nice :)

Perhaps it would be great to create a directory in boost code vault?

PS. Rationale for not providing matrices and operators related to this topic
(vector/matrix)
is not only that matrices are not finished but also I suppose that matrices
are somewhat higher level primitives and wouldn't it be rational to provide
these operations with matrix class?..

Respect,
Justinas V.D.


tiny_vector.zip
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: smart assert library comments

[John Torjo]

Hi Pavel,

> Hello John,
>
> > > 1. #include  may be replaced with #include 
> > >
> > > However Dimkunware C++ library for MSVC 6 does put  functions
> > into
> > > std:: namespace, so
> >
> > Unfortunately, it's not true (at least not for my MSVC6 ;-))
> >
> My typo. It should be DOESN'T.
>
> #include 
> using std::abort;
>
> abort()
>
> should be both portable and 'right' the C++ people as well.
>

Aaa!
But I was afraid of something and ideed it happens.
I tried compiling on VC6
#include 
using std::abort;

- and I get a compile-time error:
'abort' is not a member of std.

>
> > >
> > > 4. the catch(...) may (under Windows) eat some system exceptions which
> > > should pass. It should generally be used only at top level of
> application.
> > >
> > I assume you're talking about Assert's destructor.
> >
> Yes. Actually here you are right and catch(...) must be here.
>
> I do not have it at hand but saw somewhere that if Win32 system exception
is
> thrown it is caught by catch(...) and the throw either doesn't propagate
> anything or the context is destroyed. I am not absolutely sure how it is.

You are totally right. But I think it's better to be on the safe side.

>
> > > Anyway, I will provide a function that will do just that (use
> > OutputDebugString).
> >
> Will it be possible to chain outputs: like log file + OutputDebugString()?

In your logger , of course.
I can actually provide a helper functor that does just that.
As a matter of fact, I will provide it.

>
> > > 7. Is it possible to write into log info from applications directly?
> (good
> > > e.g. to compare timestamps later when assert happens)
> >
> > I'm not sure I understood this, but I guess not.
> > Please provide me with an example.
> >
> Example:
>
> write_to_log("huge file copying started at %s", now());
> try {
>  copy_huge_file();
> } catch(...) {
>assert(false).message("huge file copy failed, compare current timestamp
> with start timestamp to guess whare did it fail: beginning or in the
> middle");
> }
>
> Such a info is useful for control and non-interactive systems.

Aaa!
Of course, use the .msg() function. Like this:
SMART_ASSERT(false).msg("huge file copy failed, compare current
timestamp
 with start timestamp to guess whare did it fail: beginning or in the
 middle");

This will compile and run as expected.

>
> > > 9. (I am starting to fantasize now) Would it be possible to define
some
> > > global callback to write some data into log when assert happens? Could
> > there
> > > be 'stack' of these callbacks?
> >
> > ;-)))
> >
> > But this is what the logger is for ;-)
> > The logger loggs ALL assertions.
> > Your logger can be implemented as a functor. For instance, an object, in
> > which you can add/remove streams. When a message is written to the
logger,
> > the logger can then (in our example) write the context to all its
streams.
> >
> > Or did I not understand what you meant?
> >
> It is what I mean.

Great!

>
> > > what if I want to send assert to some remote machine in distributed
> > system,
> > > is there a chance to overtake the assert output completely _and_ send
it
> > > somewhere with TIMEOUT PROTECTION?
> >
> > Sorry, but I don't understand what you meant.
> > But I guess it's possible ;-
> >
> I went too wild. Will it be possible to intercept assert output and call
> user code? If so anyone may implement what he wants.

Of course. Basically, there is no such thing as "assert output". There is an
'assert_context', however.
You have two things:
- a logger
- a handler.

The logger does what it wants with assert_context, but it *should* log it
somewhere.
The handler does what it wants with assert_context, but it *should* handle
it - do something appropriate to its level.

So, in your handler, you can "intercept" every assert of a given level
(example: lvl_debug), and do whatever you want.
In other words, it is possible to have your custom code to do as you wish
(and reasonable defaults are provided).

>
> > > 4. Note to naming:
> > >
> > > Maybe BOOST_SMART_ASSERT and BOOST_SMART_VERIFY should be used by
> default
> > > and users can redefine them as they need.
> >
> > True. However, someone suggested that since the library could ( > on>) make it into STL, use SMART_ASSERT/SMART_VERIFY ().
> >
> In this case STL may rename it itself. It is Boost guideline to prefix all
> macros with BOOST_. I think v_ can be exceptions but maybe some people
will
> ask not to define it by default. Macro naming is quite easy nitpick ;-)

About STL: indeed. So, what do others think? Should I call the macros
BOOST_ASSERT, BOOST_VERIFY?

About the v_ macro: I think it's ok to have it by default (but that's just
me;-)). In case it conflicts with something, a compile error will occur, and
should point the user to the problematic code. Will see the following:

#ifndef BOOST_SMART_ASSERT_DISABLE_V_
#define v_(x) boost::smart_assert::Private::log_me((x), #x,
boost_private_assert_keeper).m_val
#endif


So, it will just #d

Re: [boost] Should we refine boost::timer

[Toon Knapen]

On Wednesday 21 May 2003 14:39, Jeff Garland wrote:
> Did you look at the attached test program which had this traits adapter?
nope. I must have missed that although I check all attachments (I think)

> static time_duration_type make_time_duration(time_rep start, time_rep end)
> {
>   assert(CLOCKS_PER_SEC == time_duration_type::rep_type::res_adjust());
>   return time_duration_type(0,0,0, end - start);
> }
I think the traits are too dependent on the time_duration_type coming from
the date-time library. It should be possible to reset the elapsed time using
a default-constructed time_duration_type and set the a time_duration_type
using an operator= instead of the constructor with 4 arguments.
But these are details that can be solved when making real-life
specialisations. So back to the overall strategy :

I think it's a good idea to provide a templated timer that can be
specialised for timing cpu-time or wall-clock time. The template-argument
however should be allowed to have different implementations
on different platforms. E.g. as I mentioned before, the clock()
function wraps around too quick. On 32-bit POSIX systems 
(CLOCKS_PER_SEC must be 1M) you have a wraparound every 72 minutes.
So I would for instance implement the cpu-timer using getrusage (on linux) etc. 

> That assumption really limits the use of the timer.  For example,
> you can't use it in a user interface where a start/stop button
> can be controlled by a user to measure the total elapsed time on
> a task that might be interupted.  For program timing there might be 
> sections of the program execution I would like to ignore.  This is 
> not possible without a stop function.

OK, agreed.

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

Re: [boost] Re: program_options lib review

[Tanton Gibbs]

> I understand why you might need additional parsers. The important point
> about them is that it's easy to add them. Since the parsing part is
> hidden behing the "parse*" functions, to add a new parser one would need
to
> only to add "parse_xml_config_file" function. Probably some of such
> functions must be added to the library --- but that depends on user
> feedback.

Ah, I guess I misunderstood.  I thought the parse* functions were just for
the command line.  Since that is not the case, then my concerns over that
are alleviated.  It would be nice to provide some common ones (name=value,
winini, environment vars, etc...)
>

> > Here are my addressable comments
> > (1) I would like to have a find_if and count_if function as I often want
> > to
> > find a parameter of the format *.field.*  It doesn't matter what the *'s
> > are
> > as long as it contains .field.  They should both take a function as a
> > parameter.
>
> Those functions should be added to variables_map, right?

correct.

> > (2) Someone else mentioned custom parameter verification.  I'm kind of
> > split
> > on this.  I don't mind it if you could pass in an arbitrary functor
(like
> > a
> > lambda library functor).  However, I also don't mind doing the
validation
> > outside of the library.  I definitely don't want the parameter function
to
> > take arbitrary parameters (like the min/max idea presented earlier) as
> > that would just be too confusing.
>
> I think 'parameter' function should not take arbitrary parameter, or we'll
> be lost in overloading ambiguities. However, user or I can write more
> functions, similiar in spirit to 'parameter', but with added semantics.
> E.g:
>
>desc.add_options()
> ("compression", range_parameter("n", 1, 9), "desired compression")
> ;
>

I would rather see something like
  desc.add_options()
  ("compression", parameter("n", (_1 >= 1 && _1 <= 9)), "desired
compression")

I think that is infinately more flexible.  There is no possible way you
could imagine how people want to validate.  However, if you wanted, you
could provide shortcuts.
  desc.add_options()
  ("compression", parameter("n", in_range(1, 9)), "desired
compression" )

If you really did not want the extra argument to parameter, then you could
tack it on like default_value.
  desc.add_options()
  ("compression", parameter("n").validate( in_range(1, 9) ),
"desired compression" )

> > (4) What if I want parameters to occur in a particular order?  For
> > example, the -kk option can only occur after the update parameter in
cvs:
> > cvs update -kk blah blah blah is legal
> > cvs -kk update blah blah blah is not
> > It would be nice to either be able to specify a mandatory ordering, or
to
> > be
> > able to find out the position of the parameter.  If you could specify a
> > mandatory ordering, then I would like it to be relative.  For instance
> > every parameter with ordering level 0 must appear before every parameter
> > with ordering level 1; however, parameters with ordering level 0 can
> > appear in any order amongst themselves.
>
> Something like that could be added, but I'll try to do that only if
> seriously pressed by some user. The reason is that I find such command
line
> syntax to be confusing. As I've mentioned some time ago, in CVS the same
> option means different things depending on position and this leads to user
> confusion, not convenience.

I understand this and won't quable over it.  It definately has its
downsides, but there are programs that use it and it would be nice to say
the lib supports it.  And, FWIW, I still have trouble with cvs command lines
:)

Tanton

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

[boost] Re: one small assert fix

[John Torjo]

- Original Message - 
From: "Pavel Vozenilek" <[EMAIL PROTECTED]>
To: "John Torjo" <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2003 11:25 PM
Subject: one small assert fix


> boost/smart_assert.hpp can have code:
> 
> #ifndef ...
> #define ...
> 
> #if _MSC_VER >= 1020
> #pragma once
> #endif
> 
> 
> 
> This could make difference in compile time for MSVC and Intel C++.

Got it! Thanks. Done. ;-)

Best,
John

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

Re: [boost] Re: smart assert library comments

[John Torjo]

> John Torjo wrote:
> >> 3. In addition to __FUNCTION_ GCC has __PRETTY_FUNCTION__ and C99
> >> __func__ (I think). Other platforms may have their own (like
> >> __function__).
> >
> > Thanks!
> > Basically, I would be interested in all of these unportable macros.
> > The more the merrier, since the more information we can supply about a
> > failed assertion, the better!
> >
> > If anyone has knowledge about these, please let me know. Thanks.
>
> See boost/current_function.hpp.

Thanks. Did it.
However, I guess a possible improvement of current_function.hpp would be one
more macro - sigh -, something like:
BOOST_CURRENT_FUNCTION_EXISTS.

I suppose:

#undef BOOST_CURRENT_FUNCTION_EXISTS

#if defined(__GNUC__)

# define BOOST_CURRENT_FUNCTION __PRETTY_FUNCTION__
#define BOOST_CURRENT_FUNCTION_EXISTS

#elif defined(__FUNCSIG__)

# define BOOST_CURRENT_FUNCTION __FUNCSIG__
#define BOOST_CURRENT_FUNCTION_EXISTS

#elif defined(__BORLANDC__)

# define BOOST_CURRENT_FUNCTION __FUNC__
#define BOOST_CURRENT_FUNCTION_EXISTS

#elif defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901)

# define BOOST_CURRENT_FUNCTION __func__
#define BOOST_CURRENT_FUNCTION_EXISTS

#else

# define BOOST_CURRENT_FUNCTION "(unknown)"

#endif

What do you think?


Best,
John



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

[boost] Re: program_options lib review

[Vladimir Prus]

Hi Tanton,

Tanton Gibbs wrote:

> I have to say that I'm a little torn over this library.  I really like its
> simplicity and usefulness; however, I wish it were more of a facade on a
> more complex library.  For example, I would like to be able to have
> multiple config file parsers for winini, tag=value,xml, or other config
> file types. 

I understand why you might need additional parsers. The important point
about them is that it's easy to add them. Since the parsing part is
hidden behing the "parse*" functions, to add a new parser one would need to
only to add "parse_xml_config_file" function. Probably some of such
functions must be added to the library --- but that depends on user
feedback. 

> Also, I would like to see canned custom parsers for
> -fparm/-fno-parm and
> +parm -parm syntax.  

I think it's possible to collect some number of canned parsers that are
commonly requested.

> Here are my addressable comments
> (1) I would like to have a find_if and count_if function as I often want
> to
> find a parameter of the format *.field.*  It doesn't matter what the *'s
> are
> as long as it contains .field.  They should both take a function as a
> parameter.

Those functions should be added to variables_map, right?

> (2) Someone else mentioned custom parameter verification.  I'm kind of
> split
> on this.  I don't mind it if you could pass in an arbitrary functor (like
> a
> lambda library functor).  However, I also don't mind doing the validation
> outside of the library.  I definitely don't want the parameter function to
> take arbitrary parameters (like the min/max idea presented earlier) as
> that would just be too confusing.

I think 'parameter' function should not take arbitrary parameter, or we'll
be lost in overloading ambiguities. However, user or I can write more
functions, similiar in spirit to 'parameter', but with added semantics.
E.g:

   desc.add_options()
("compression", range_parameter("n", 1, 9), "desired compression")
;

> (3) As another pointed out, the documentation is definitely lacking.  I
> would like less of code documentation and more of user documentation.  I
> would like to see more examples with sample output and a slow moving
> tutorial that covers all of the features.

Point taken.

> (4) What if I want parameters to occur in a particular order?  For
> example, the -kk option can only occur after the update parameter in cvs:
> cvs update -kk blah blah blah is legal
> cvs -kk update blah blah blah is not
> It would be nice to either be able to specify a mandatory ordering, or to
> be
> able to find out the position of the parameter.  If you could specify a
> mandatory ordering, then I would like it to be relative.  For instance
> every parameter with ordering level 0 must appear before every parameter
> with ordering level 1; however, parameters with ordering level 0 can
> appear in any order amongst themselves.

Something like that could be added, but I'll try to do that only if
seriously pressed by some user. The reason is that I find such command line
syntax to be confusing. As I've mentioned some time ago, in CVS the same
option means different things depending on position and this leads to user
confusion, not convenience.

> Now for comments on what other people have said.
> (1) I also like parameter as the last argument instead of the middle
> one...it just flows better to me.

OK, noted.

> (2) I like the parameter function and don't really like the syntax that
> used the >> operator...it just looks odd to me.
> (3) I like the parameter function taking the argument by pointer as it is
> easier to understand what is happening.
> (4) The exception name "error" doesn't bother me...I kinda like it :)

OK.

> All in all it looks to be a good library.  However, I may have missed the
> ability to define a custom config file format.  If I didn't then I fully
> think that needs to be added or config files need to be dropped entirely.

As I've mentioned above, adding new config file format is as simple as
adding a new function. That's simple, but it works.

Thanks,
Volodya



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

Re: [boost] Re: Re: smart assert (was:ENFORCE/betterassertiontechnique)

[John Torjo]

>
> However, given the generally accepted meaning of an assertion, I
> have no problem with using BOOST_ASSERT for debug only tests and
> BOOST_VERIFY for debug and release tests.  (Another name might be
> BOOST_CHECK.)  I don't do Windows programming -- or at least I
> haven't done any in a few years -- so I'm not wedded to any
> connotation of "VERIFY."

They are called SMART_ASSERT and SMART_VERIFY now, after receiving a
suggestion. Check it out - www.torjo.com/smart_assert.zip or
http://aspn.activestate.com/ASPN/Mail/Message/boost/1644092
I will post an update soon.

>
> Another scheme I've used in the past is a manifest constant to
> control such assertion macros at one more level: production
> versus non-production builds.  The idea is that, using my names
> above, BOOST_ASSERT appears in release builds unless
> BOOST_PRODUCTION_RELEASE is defined.  The latter case compiles
> away the assertion code.
>

Indeed. I have such a thing: BOOST_SMART_ASSERT_MODE (a macro that can be
defined by the programmer)
0 - "release"
1 - "debug"

If not defined, I take the defaults:
- NDEBUG defined - "release"
- NDEBUG not defined - "debug"


> The rationale for that approach is that having assertions in a
> release build means you get the performance benefit of optimized
> code -- which is terribly important here -- while retaining the
> assertions to validate conditions.  Once the application has
> proven itself in rigorous testing, one can define
> BOOST_PRODUCTION_RELEASE, rebuild, do some testing, and release
> the product.  Thus, the release build with
> BOOST_PRODUCTION_RELEASE defined gives you the ordinary behavior
> of assert -- the assertions don't appear in the build.
>

True.

Best,
John

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

[boost] Re: Formal Review: Command Line & Config library

[Vladimir Prus]

Hi Pavol,

Pavol Droba wrote:
> I have tried to use program_options library. I have compiled the library,
> ran the examples and then incorporated the library into one of my
> projects.

Thanks for putting time into this!

> First and in my opinion the most important one is the matter of
> documentation. I find it very hard to use. Examples are quite good to give
> a nice overview of the library and that's sufficient for a decent start.
> But searching for the details is quite difficult. I would prefer a few
> chapters explaining various components of the library, each followed by a
> reference. Right now I find the documentation rather hard to use. Actuay
> it is very close to browsing through header files and in my opinion this
> is not what the documentation should be about.

I'll keep this in mind. In fact, I plan to convert all the documentation
into BoostBook is the library is accepted. The Doxygen is very nice --- in
fact, it helps very much to keep everything documented. But I found it
rather limiting for writing various "overview" pages. Hope new
documentation will be better.

[...]
> * Arguments
> 
>As it was already mentioned here, arguments should have the same
>support as options. Validation and format checking would be appretiated

OK, I'm already thinking about possible approaches.

> * Validation
>
>Library allows to supports validation and parsing of option parameters,
>but I thinks it is rather limited. It is possible to define
>user-specific behaviour, but it would be helpful, if some common
>formats would be suported.
> 
>For instance:
>   * Various integer types ( not just int ) with boundary checking.
> Something like
>paramter( "count", 1, 4, &count ) // 1-Min and 4-Max
>value

It's funny that the very first prototype version had this facility. In
surely can be added to the current version if there's such need.


>   * Format specification and checking for string. Regex specification
>   of something like scanf would be nice.
> This can be useful for example to check if the parameter is a
> filename.

Could you clarify a bit how scanf-like specification can work? You mean it
can be used to specify syntax? 

> * Environment & Others
> 
>The library tries to unify the access to program options from command
>line and from ini files. This is very nice feature because it is
>removing the need for doing generaly the same thing twice. It would be
>nice if some other sources of paramers could be incorporated as well.
>Particulary the enviromnmet is often used to exchange arguments. Given
>the fact that it consist of a set of pairs "variable=value" it is very
>similar to the ini file and so it souldn't be hard to implement.

Thanks for the suggestion! It's quite right.
 
>For windows platform the registry comes to play as another source of
>options.

Yep, that source was considered as alternative from the very start. I've
seen some project start with a command line, then add config files and then
need registry on Windows. Registry is not yet supported because I wanted to
find out if there's support to the idea of uniform access to all
configuration means.

Thanks,
Volodya


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

[boost] Fix: current_function.hpp

[Pavel Vozenilek]

current_function.hpp doesn't include Intel C++ where __FUNCTION__ can be
used. It is more-less equivalent of GCC __FUNCTION__ (not the pretty one).

No other similar macro works. It is not listed in official documentation but
(likely) provided as GCC compatibility feature.

Tested configurations:
- Intel C++ 6.0 plugin in MSVC 6
- Intel C++ 7.0 plugin in MSVC 6
- Intel C++ 7.0 standalone

(Number of configurations is much larger, including Linux version).

Btw: what is purpose of  current_function_helper()?

/Pavel



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

[boost] program_options lib review

[Tanton Gibbs]

I have to say that I'm a little torn over this library.  I really like its
simplicity and usefulness; however, I wish it were more of a facade on a
more complex library.  For example, I would like to be able to have multiple
config file parsers for winini, tag=value,xml, or other config file types.
Also, I would like to see canned custom parsers for -fparm/-fno-parm and
+parm -parm syntax.  However, as it stands I think it is a good contribution
and I would definitely use it.  I will withhold my vote until I have a
chance to play around with it some more.

Here are my addressable comments
(1) I would like to have a find_if and count_if function as I often want to
find a parameter of the format *.field.*  It doesn't matter what the *'s are
as long as it contains .field.  They should both take a function as a
parameter.
(2) Someone else mentioned custom parameter verification.  I'm kind of split
on this.  I don't mind it if you could pass in an arbitrary functor (like a
lambda library functor).  However, I also don't mind doing the validation
outside of the library.  I definitely don't want the parameter function to
take arbitrary parameters (like the min/max idea presented earlier) as that
would just be too confusing.
(3) As another pointed out, the documentation is definitely lacking.  I
would like less of code documentation and more of user documentation.  I
would like to see more examples with sample output and a slow moving
tutorial that covers all of the features.
(4) What if I want parameters to occur in a particular order?  For example,
the -kk option can only occur after the update parameter in cvs:
cvs update -kk blah blah blah is legal
cvs -kk update blah blah blah is not
It would be nice to either be able to specify a mandatory ordering, or to be
able to find out the position of the parameter.  If you could specify a
mandatory ordering, then I would like it to be relative.  For instance every
parameter with ordering level 0 must appear before every parameter with
ordering level 1; however, parameters with ordering level 0 can appear in
any order amongst themselves.

Now for comments on what other people have said.
(1) I also like parameter as the last argument instead of the middle
one...it just flows better to me.
(2) I like the parameter function and don't really like the syntax that used
the >> operator...it just looks odd to me.
(3) I like the parameter function taking the argument by pointer as it is
easier to understand what is happening.
(4) The exception name "error" doesn't bother me...I kinda like it :)

All in all it looks to be a good library.  However, I may have missed the
ability to define a custom config file format.  If I didn't then I fully
think that needs to be added or config files need to be dropped entirely.
Even environment variables could be used with a custom config file parser.
Also, the documentation leaves much to be desired.  If those two concerns
are addressed then I will fully support this library.

Tanton

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

Re: [boost] shared_ptr/weak_ptr and thread-safety

[Michael Ost]

Forgive me if I am jumping in inappropriately but if this is of
interest... I recently started using shared_ptr to solve a problem in my
app, and found that I needed to set BOOST_DISABLE_THREADS
since I don't need the thread safety built in to shared_ptr. The app
handles that itself.

But this sledgehammer approach means I can't use the boost thread
classes in the same app, which I was considering doing.

I wouldn't mind another BOOST_xxx precompiler setting to determine
thread usage in shared_ptr, since the designers appear uninterested in
the parameterization solution.

Cheers... mo

On Thu, 2003-05-22 at 10:41, Alexander Terekhov wrote:
> 
> 
>  Original Message 
> Message-ID: <[EMAIL PROTECTED]>
> Date: Thu, 22 May 2003 19:37:13 +0200
> From: Alexander Terekhov <[EMAIL PROTECTED]>
> Newsgroups: comp.programming.threads
> Subject: shared_ptr/weak_ptr and thread-safety
> References: ... <[EMAIL PROTECTED]>
> 
> Joseph Seigh wrote:
> > 
> > Alexander Terekhov wrote:
> > >
> > > Okay. How about 'super_thread_safe_shared_ptr<>'? ;-)
> > >
> > > Seriously, "atomic_ptr" doesn't really convey what it is. You might
> > > also want to consider making it either blocking [maximum portability;
> > > but pretty much useless ;-)] or non-blocking (with "emphemeral" stuff
> > > and/or whatever tricks). Oder?
> > >
> > 
> > Well, Detlefs calls it lock-free reference counting.  But Boost
> > would probably call what they're doing with thread-safe reference
> > counting lock-free also, and they are not the same.  
> 
> They don't call it "lock-free". Here's what they say:
> 
> http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
> (A Proposal to Add General Purpose Smart Pointers to...)
> 
> "
>  The count structure C has the following members:
> 
>  Virtual table pointer (C is polymorphic); 
>  Use count; 
>  Weak count; 
>  Mutex (for multithreaded builds); 
>  Original pointer passed to the constructor; 
>  Deleter.
>  
>  The mutex presents another target for platform-specific 
>  optimizations. On Windows, we have been able to use a simple 
>  one-word spinlock instead of a 6 word CRITICAL_SECTION. The 
>  portable architecture of the implementation that abstracts 
>  the mutex concept in a separate class prevents further 
>  optimizations, like reusing the use count word as the 
>  spinlock, or using the Windows API InterlockedIncrement, 
>  InterlockedDecrement, and InterlockedCompareExchange 
>  primitives to attempt to eliminate the mutex altogether. 
>  Nevertheless, we believe that such optimizations are 
>  possible.
>  "
> 
> >  The meaning
> > of atomic w.r.t java pointers is or should be well understood, so
> > atomic something would be indicated.  Also, it wouldn't preclude
> > a non lock-free implementation, though you would lose the bemefits
> > of lock-free.
> > 
> > Maybe atomic_shared_ptr.
> 
> Well, I'd love to have a policy-based framework that would 
> allow me to specify the *thread-safety policy*:
> 
>   thread_safety::unsafe
> 
> "naked" count(s)
> 
>   thread_safety::basic
> 
> pthread_refcount_t stuff ()
> 
>   thread_safety::strong
> 
> your "atomic" stuff
> 
> or something like that. Note that for the blocking stuff, one 
> would REALLY want to have some support for priority protocols 
> (priority protection or priority inheritance) to fight the 
> "unbounded priority inversion" problem in the "realtime" apps.
> 
> regards,
> alexander.
> 
> --
> http://terekhov.de/pthread_refcount_t/draft-edits.txt
> 
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

[boost] program_options lib: how to denote return values?

[Chuck Messenger]

Rob Stewart wrote:
From: "James Curran" <[EMAIL PROTECTED]>
Chuck Messenger wrote:

* add_options() should use references rather than pointers

"Pointer for return value" is C semantics.  In C++,
pointers denote optional values.  Non-const references are for return
values.
   I disagree *strongly*.   In C and C++, the address-of syntax clearly
indicates that this is a value that will be changed.  Your suggestion of
using a non-const reference would require me to check the header file to
find the signature of _every_single_F#$^%ing_function to figure out which
parameters are changed and which one's aren't.  (particularly in the case of
Disagree strongly all you want, but I only use pointers to
indicate optional arguments and to pass references (general
meaning of the word) to objects that are expected to outlive the
object to which they are given (usually in the ctor).  In the
former case, the argument may be null so I check for that case.
In the latter, I often use RCSPs, but not always.
I don't use non-const reference parameters often (and when I do
they are always the first argument(s)).  I find they work
intuitively.  You see, such functions always indicate, by their
very name, that they are providing a value, so the name quite
reasonably documents the output parameter.
Using pointers in this context would be counterintuitive to me.

Ultimately, someone will be disappointed.
OK, how about this syntax, to make it much more clear what is being 
returned (and, at the same time, to reduce the verbiage):

desc.add_options()
...
(param("magic|value|magic value for the program") >> magic)
(param("val||some value with a default", defaultValue) >> val)
...
;
I've combined all 3 strings into one argument. Why have 3? It just takes 
up space. The 3 strings are separated by | (or pick a better seperator 
char).  param() is a template function.  I haven't tested this, but it 
seems like it could be made to work...

- Chuck

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

[boost] Re: Formal Review: Command Line & Config library

[Chuck Messenger]

Vladimir Prus wrote:
Chuck Messenger wrote:


* Library-managed default values
I think it good idea. Need to flesh some details a bit.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Managed_Default_Values_-_Program_Options_Suggestion
Replace default_value() with optional 3rd arg to parameter(); hardwired
[...] is fine.


OK, I think we've mostly agreed. See the wiki.
I have new thoughts -- see wiki.  Basically, simplify things by 
eliminating paramter() and default_value() -- turning them into regular 
arguments -- and by combining the first 2 string args.  This would make 
for much less typing.

* Adaptive formatting (first field width)
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Adaptive_For
matting_-_First_Field_Width_-_Program_Options_Suggestion
We can't ignore that looks matter.  Ugly won't fly.


The question is: what if first field width is larger than maximum width? What 
can we do? 
Then let the long column be out of alignment.  There could be a function 
to set the max column width.

* program_name() and %progname%
I'm unsure on both of them. See my comments on Wiki
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Name
_-_Program_Options_Suggestion
Show an example of "hardcoded" program name.


For example: 
options_description desc("Usage: my_program 1.0.1  OPTIONS\n"
 "OPTIONS");
As on wiki: what if I change the name of my program? (which happens 
alot).  It's a natural thing for program_options to extract the program 
name, since you're already passing it argv[0].

* Mandatory options
Good idea. Output formatting is the only issue with me.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Mandatory_Options_-_Program_Options_Suggestion
I like your format.
Great! We've agreed.
The only thing is to figure out how to specify your format.  Perhaps 
with something like:

options_description desc("Usage: %progname% %args% OPTIONS\n"
 "MANDATORY OPTIONS:\n"
 "%mandatory_options%"
 "OPTIONS:\n"
 "%optional_options%");
This could be the default string.  (obviously, don't use 
"optional_options" literally :-)

* add_options() should use references rather than pointers
That's style issue, and I'm not partial. Let's hear other opinions.
See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
Should_Use_References_Rather_Than_Pointers_-_Program_Options_Suggestion
I don't agree.  "Pointer for return value" is C semantics.  In C++,
pointers denote optional values.  Non-const references are for return
values.


Ehm... the "pointer for return values" rule is from TC++PL, IIRC.
TC++PL is Stroustrup, right?  I think I found the quote you're thinking 
of.  In section 5.5 (3rd edition):

To keep a program readable, it is often best to avoid functions that
modify their arguments.  Instead, you can return a value from the
function explicitly or require a pointer argument:
int next(int p) { return p+1; }

void incr(int *p) { (*p)++; }

void g()
{
int x = 1;
increment(x);
x = next(x);
incr(&x);
}
The increment(x) notation doesn't give a clue to the reader that x's
value is being modified, the way x=next(x) and incr(&x) does.
Consequently, "plain" reference arguments should be used only where
the name of the function gives a strong hint that the reference
argument is modified.
I hate to disagree with Stroustrup, but ... in this case, it's pretty 
obvious that increment(x) is going to change x.  What he's saying is 
that passing the address can serve as an aid to comprehension in 
ambiguous situations.

I'd argue that in the case of parameter(), it isn't ambiguous.  But, 
then again, I can see that a programmer could be confused as to which 
parameter was the default value, if care wasn't taken.  Perhaps this 
argues in favor of your default_value() call.

Anyway, I can accept that many people (maybe even most, or even everyone 
but me) agree with your semantics of "use pointer for return value". 
Maybe others will pipe in...

- Chuck

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

[boost] Re: shared_ptr/weak_ptr and thread-safety

[Alexander Terekhov]

Joseph Seigh wrote:
> 
> Alexander Terekhov wrote:
> >
> > Joseph Seigh wrote:
> > > Well, Detlefs calls it lock-free reference counting.  But Boost
> > > would probably call what they're doing with thread-safe reference
> > > counting lock-free also, and they are not the same.
> >
> > They don't call it "lock-free". Here's what they say:
> >
> > http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
> > (A Proposal to Add General Purpose Smart Pointers to...)
> >
> > "
> >  The count structure C has the following members:
> >
> >  Virtual table pointer (C is polymorphic);
> >  Use count;
> >  Weak count;
> >  Mutex (for multithreaded builds);
> >  Original pointer passed to the constructor;
> >  Deleter.
> >  
> >  The mutex presents another target for platform-specific
> >  optimizations. On Windows, we have been able to use a simple
> >  one-word spinlock instead of a 6 word CRITICAL_SECTION. The
> >  portable architecture of the implementation that abstracts
> >  the mutex concept in a separate class prevents further
> >  optimizations, like reusing the use count word as the
> >  spinlock, or using the Windows API InterlockedIncrement,
> >  InterlockedDecrement, and InterlockedCompareExchange
> >  primitives to attempt to eliminate the mutex altogether.
> >  Nevertheless, we believe that such optimizations are
> >  possible.
> >  "
> 
> The fact that they consider and have done simplistic spin locks
> speaks for itself.  

Yeah. http://lists.boost.org/MailArchives/boost/msg44460.php

> Also, they make a whole lot of distinctions
> that don't translate very well into a threaded environment.
> Their style of semantic definition with that pre and post internal
> data state stuff doesn't work in multi-threading. 

I think it's fine. Please see the definitions of shared_ptr and
weak_ptr thread "safeties" (below).
 
>The one thing
> you usually cannot reliably observe in multi-threading is internal data
> state.  You have to use other mechanisms to define semantics for
> multi-threading. 

I don't think so.
 
>   To say nothing of their multiple attempts to
> deal with data "ownership".  It's why they have so many pointer
> types, all compromised in some degree or other for some small
> incremental benefit.

;-)

> 
> >
> > >  The meaning
> > > of atomic w.r.t java pointers is or should be well understood, so
> > > atomic something would be indicated.  Also, it wouldn't preclude
> > > a non lock-free implementation, though you would lose the bemefits
> > > of lock-free.
> > >
> > > Maybe atomic_shared_ptr.
> >
> > Well, I'd love to have a policy-based framework that would
> > allow me to specify the *thread-safety policy*:
> >
> >   thread_safety::unsafe
> >
> > "naked" count(s)
> >
> >   thread_safety::basic
> >
> > pthread_refcount_t stuff ()
> >
> >   thread_safety::strong
> >
> > your "atomic" stuff
> >
> > or something like that. Note that for the blocking stuff, one
> > would REALLY want to have some support for priority protocols
> > (priority protection or priority inheritance) to fight the
> > "unbounded priority inversion" problem in the "realtime" apps.
> >
> 
> I'm never quite sure what "thread-safe" really means.  It seems
> to get used in different ways sometimes. 

thread_safety::unsafe means that *copying* AND all mutation 
operations on shared_ptr/weak_ptr copies (all pointing to the 
same object; "typed-null" including) shall be *synchronized*; 
otherwise, the behavior is undefined. Read-only stuff (copying
aside) can be done concurrently.

thread_safety::basic means that all "const" operations 
(including copying) can be done concurrently, but mutations 
shall be synchronized; otherwise, the behavior is undefined.

thread_safety::strong means "do-whatever-you-want-and-don't-
care-about-synchronization" (i.e. you can also mutate shared_ptr 
and weak_ptr objects *concurrently* without any synchronization
because it's fully synchronized "internally").
 
>  Atomic is easy to define.
> It just means that you will only ever read some previously stored
> value.

The C and C++ standards already mandate that! Here's what C99 
says, for example:

"The lifetime of an object is the portion of program execution 
 during which storage is guaranteed to be reserved for it. An 
 object exists, has a constant address, and retains its last-
 stored value throughout its lifetime."

regards,
alexander.

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

[boost] Re: Re: Formal Review: Command Line & Config library

[James Curran]

Rob Stewart wrote:
> Disagree strongly all you want, but I only use pointers to
> indicate optional arguments and to pass references (general
> meaning of the word) to objects that are expected to outlive the
> object to which they are given (usually in the ctor).  In the
> former case, the argument may be null so I check for that case.
> In the latter, I often use RCSPs, but not always.
>
> I don't use non-const reference parameters often (and when I do
> they are always the first argument(s)).  I find they work
> intuitively.  You see, such functions always indicate, by their
> very name, that they are providing a value, so the name quite
> reasonably documents the output parameter.

Actually, I think you agree more with me than you think.

Here is a sample of usage we are discussion:

 desc.add_options()
// First parameter describes option name/short name
// The second is parameter to option
// The third is description
("help,h", "", "print usage message")
("output,o", parameter("", &ofile), "pathname for
output");

Recast it to use a non-const reference parameter for "ofile" following your
guidelines of "the first argument" and "functions always indicate, by their
very name, that they are providing a value".


-- 
Truth,
James Curran
www.noveltheory.com (personal)
www.njtheater.com (professional)



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

Re: [boost] Re: Re: smart assert (was: ENFORCE/betterassertiontechnique)

[Rob Stewart]

From: "John Torjo" <[EMAIL PROTECTED]>
> 
> > > If VERIFY is used in MFC to mean an assert even in release mode then
> that
> > is
> > > probably the best name.
> > In MFC it doesn't have that meaning though. It means that the expression
> > passed to VERIFY will get evaluated in the release build but the result of
> > this expression will not get checked in release build.
> 
> Right!
> However, I think this would be a great feature (and a good name -
> BOOST_VERIFY) - to allow the same behaviour as ASSERT in release as well.
> What do you think? Do you think of a better name?

We use -- after name translation -- the following:

BOOST_DEBUG_ASSERT
BOOST_ASSERT

We follow the philosophy of keeping assertions in production
code; they've kept us from losing lots of money when a program
runs wild.  Therefore, we normally use (the moral equivalent to)
BOOST_ASSERT and only in some circumstances use
BOOST_DEBUG_ASSERT (such as to call a second code path to
validate normal calculations).

However, given the generally accepted meaning of an assertion, I
have no problem with using BOOST_ASSERT for debug only tests and
BOOST_VERIFY for debug and release tests.  (Another name might be
BOOST_CHECK.)  I don't do Windows programming -- or at least I
haven't done any in a few years -- so I'm not wedded to any
connotation of "VERIFY."

Another scheme I've used in the past is a manifest constant to
control such assertion macros at one more level: production
versus non-production builds.  The idea is that, using my names
above, BOOST_ASSERT appears in release builds unless
BOOST_PRODUCTION_RELEASE is defined.  The latter case compiles
away the assertion code.

The rationale for that approach is that having assertions in a
release build means you get the performance benefit of optimized
code -- which is terribly important here -- while retaining the
assertions to validate conditions.  Once the application has
proven itself in rigorous testing, one can define
BOOST_PRODUCTION_RELEASE, rebuild, do some testing, and release
the product.  Thus, the release build with
BOOST_PRODUCTION_RELEASE defined gives you the ordinary behavior
of assert -- the assertions don't appear in the build.


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

[boost] Re: shared_ptr/weak_ptr and thread-safety

[Alexander Terekhov]

Joseph Seigh wrote:
> 
> Alexander Terekhov wrote:
> >
> > Joseph Seigh wrote:
> > > Well, Detlefs calls it lock-free reference counting.  But Boost
> > > would probably call what they're doing with thread-safe reference
> > > counting lock-free also, and they are not the same.
> >
> > They don't call it "lock-free". Here's what they say:
> >
> > http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
> > (A Proposal to Add General Purpose Smart Pointers to...)
> >
> > "
> >  The count structure C has the following members:
> >
> >  Virtual table pointer (C is polymorphic);
> >  Use count;
> >  Weak count;
> >  Mutex (for multithreaded builds);
> >  Original pointer passed to the constructor;
> >  Deleter.
> >  
> >  The mutex presents another target for platform-specific
> >  optimizations. On Windows, we have been able to use a simple
> >  one-word spinlock instead of a 6 word CRITICAL_SECTION. The
> >  portable architecture of the implementation that abstracts
> >  the mutex concept in a separate class prevents further
> >  optimizations, like reusing the use count word as the
> >  spinlock, or using the Windows API InterlockedIncrement,
> >  InterlockedDecrement, and InterlockedCompareExchange
> >  primitives to attempt to eliminate the mutex altogether.
> >  Nevertheless, we believe that such optimizations are
> >  possible.
> >  "
> 
> The fact that they consider and have done simplistic spin locks
> speaks for itself.  Also, they make a whole lot of distinctions
> that don't translate very well into a threaded environment.
> Their style of semantic definition with that pre and post internal
> data state stuff doesn't work in multi-threading.  The one thing
> you usually cannot reliably observe in multi-threading is internal data
> state.  You have to use other mechanisms to define semantics for
> multi-threading.  To say nothing of their multiple attempts to
> deal with data "ownership".  It's why they have so many pointer
> types, all compromised in some degree or other for some small
> incremental benefit.
> 
> >
> > >  The meaning
> > > of atomic w.r.t java pointers is or should be well understood, so
> > > atomic something would be indicated.  Also, it wouldn't preclude
> > > a non lock-free implementation, though you would lose the bemefits
> > > of lock-free.
> > >
> > > Maybe atomic_shared_ptr.
> >
> > Well, I'd love to have a policy-based framework that would
> > allow me to specify the *thread-safety policy*:
> >
> >   thread_safety::unsafe
> >
> > "naked" count(s)
> >
> >   thread_safety::basic
> >
> > pthread_refcount_t stuff ()
> >
> >   thread_safety::strong
> >
> > your "atomic" stuff
> >
> > or something like that. Note that for the blocking stuff, one
> > would REALLY want to have some support for priority protocols
> > (priority protection or priority inheritance) to fight the
> > "unbounded priority inversion" problem in the "realtime" apps.
> >
> 
> I'm never quite sure what "thread-safe" really means.  It seems
> to get used in different ways sometimes.  Atomic is easy to define.
> It just means that you will only ever read some previously stored
> value.
> 
> Joe Seigh

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

[boost] Linux regression test volunteer needed

[Beman Dawes]

Alkis Evlogimenos, who has been doing a great job running the Linux 
regression tests, is moving to Urbana-Champaign, Illinois to pursue a Ph.D. 
in CS at the University of Illinois.

Thanks again to Alkis!

He won't be available to continue running tests this summer. That means we 
need a volunteer willing to run the Boost regression tests on Linux. Please 
reply publicly or privately if you are interested in volunteering.

Thanks,

--Beman

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

Re: [boost] Re: [lambda] gcc 2.95.2?

[Jaakko Jarvi]

I applied the patch. So for gcc < 2.96, lambda now includes deque, and
works as a compensation for this extra dependency.

  Jaakko

On Thu, 22 May 2003, Daniel Frey wrote:

> Jaakko Jarvi wrote:
> > I can't now even get the deque error you mention, can you send me
> > the error listing (maybe outside of boost list). Maybe there is a better
> > way to fix it instead of including deque.
>
> The error was exactly what I quoted in the first posting of this thread.
>   The gcc uses a non-conformant deque which has a third parameter, thus
> the forward declaration doesn't work.
>
> Here's the patch for boost/lambda/detail/operator_return_type_traits.hpp:
>
> 26a27,37
>  > // The GCC 2.95.x uses a non-conformant deque
>  > #if BOOST_WORKAROUND(__GNUC__, == 2) && __GNUC_MINOR__ <= 96
>  > #  include 
>  > #else
>  >
>  > namespace std {
>  >  template  class deque;
>  > }
>  >
>  > #endif
>  >
> 869d879
> <  template  class deque;
>
> Please note that I'm not sure about the status of gcc 2.95.3 or other
> sub-versions, so please someone with more experience have a look at
> this, I'm sure it can be improved :)
>
> Regards, Daniel
>
> --
> Daniel Frey
>
> aixigo AG - financial training, research and technology
> Schloß-Rahe-Straße 15, 52072 Aachen, Germany
> fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
> eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [thread] patch to recursive_mutex.cpp

[Christopher Currie]

All,

I believe there is a bug in the BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE 
implementation of recursive_try_mutex::do_trylock. The bug is the result 
of an invalid assertion, that pthread_mutex_trylock should always return 
0. The attached test case demonstrates the error. If the following patch 
is applied, this test runs without errors. Comments and corrections are 
appreciated.

Thanks,
Christopher Currie
[EMAIL PROTECTED] [14:21:27] [~/src/boost/libs/thread/src]
$ cvs diff -c recursive_mutex.cpp
Index: recursive_mutex.cpp
===
RCS file: /cvsroot/boost/boost/libs/thread/src/recursive_mutex.cpp,v
retrieving revision 1.13
diff -c -r1.13 recursive_mutex.cpp
*** recursive_mutex.cpp 23 Feb 2003 17:38:11 -  1.13
--- recursive_mutex.cpp 22 May 2003 18:22:40 -
***
*** 495,501 
  #   if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE)
  int res = 0;
  res = pthread_mutex_trylock(&m_mutex);
! assert(res == 0);
  if (res == 0)
  {
--- 495,501 
  #   if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE)
  int res = 0;
  res = pthread_mutex_trylock(&m_mutex);
! assert( (res == 0) || (res == EBUSY) );
  if (res == 0)
  {
// Copyright (C) 2003
// Christopher Currie, William E. Kempf
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without fee,
// provided that the above copyright notice appear in all copies and
// that both that copyright notice and this permission notice appear
// in supporting documentation.  The authors make no representations
// about the suitability of this software for any purpose.
// It is provided "as is" without express or implied warranty.

#include 
#include 
#include 

#include 
#include 

#define DEFAULT_EXECUTION_MONITOR_TYPE execution_monitor::use_sleep_only
#include "util.inl"

template 
struct try_lock_thread
{
typedef M mutex_type;
typedef typename M::scoped_try_lock try_lock_type;
typedef void result_type;

void operator()( mutex_type & mutex, bool first )
{
  try_lock_type lock( mutex, false );
  BOOST_CHECK( first ? lock.try_lock() : !lock.try_lock() );
  if ( first )
{
  boost::function0 function =
 boost::bind( try_lock_thread(),
  ref( mutex ),
  false );
  boost::thread thread( function );
  thread.join();
}
}
};

void test_recursive_try_mutex()
{
boost::recursive_try_mutex mutex;
boost::function0 function = 
  boost::bind( try_lock_thread(),
   ref( mutex ),
   true );
boost::thread thread( function );
thread.join();
}

boost::unit_test_framework::test_suite* init_unit_test_suite(int, char*[])
{
boost::unit_test_framework::test_suite* test =
BOOST_TEST_SUITE("Boost.Threads: recursive_try_mutex test case");

test->add(BOOST_TEST_CASE(&test_recursive_try_mutex));

return test;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Formal Review: Command Line & Config library

[Rob Stewart]

From: "James Curran" <[EMAIL PROTECTED]>
> Chuck Messenger wrote:
> >> * add_options() should use references rather than pointers
> 
> > "Pointer for return value" is C semantics.  In C++,
> > pointers denote optional values.  Non-const references are for return
> > values.
> 
> I disagree *strongly*.   In C and C++, the address-of syntax clearly
> indicates that this is a value that will be changed.  Your suggestion of
> using a non-const reference would require me to check the header file to
> find the signature of _every_single_F#$^%ing_function to figure out which
> parameters are changed and which one's aren't.  (particularly in the case of

Disagree strongly all you want, but I only use pointers to
indicate optional arguments and to pass references (general
meaning of the word) to objects that are expected to outlive the
object to which they are given (usually in the ctor).  In the
former case, the argument may be null so I check for that case.
In the latter, I often use RCSPs, but not always.

I don't use non-const reference parameters often (and when I do
they are always the first argument(s)).  I find they work
intuitively.  You see, such functions always indicate, by their
very name, that they are providing a value, so the name quite
reasonably documents the output parameter.

Using pointers in this context would be counterintuitive to me.

Ultimately, someone will be disappointed.


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

[boost] shared_ptr/weak_ptr and thread-safety

[Alexander Terekhov]

 Original Message 
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 22 May 2003 19:37:13 +0200
From: Alexander Terekhov <[EMAIL PROTECTED]>
Newsgroups: comp.programming.threads
Subject: shared_ptr/weak_ptr and thread-safety
References: ... <[EMAIL PROTECTED]>

Joseph Seigh wrote:
> 
> Alexander Terekhov wrote:
> >
> > Okay. How about 'super_thread_safe_shared_ptr<>'? ;-)
> >
> > Seriously, "atomic_ptr" doesn't really convey what it is. You might
> > also want to consider making it either blocking [maximum portability;
> > but pretty much useless ;-)] or non-blocking (with "emphemeral" stuff
> > and/or whatever tricks). Oder?
> >
> 
> Well, Detlefs calls it lock-free reference counting.  But Boost
> would probably call what they're doing with thread-safe reference
> counting lock-free also, and they are not the same.  

They don't call it "lock-free". Here's what they say:

http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1450.html
(A Proposal to Add General Purpose Smart Pointers to...)

"
 The count structure C has the following members:

 Virtual table pointer (C is polymorphic); 
 Use count; 
 Weak count; 
 Mutex (for multithreaded builds); 
 Original pointer passed to the constructor; 
 Deleter.
 
 The mutex presents another target for platform-specific 
 optimizations. On Windows, we have been able to use a simple 
 one-word spinlock instead of a 6 word CRITICAL_SECTION. The 
 portable architecture of the implementation that abstracts 
 the mutex concept in a separate class prevents further 
 optimizations, like reusing the use count word as the 
 spinlock, or using the Windows API InterlockedIncrement, 
 InterlockedDecrement, and InterlockedCompareExchange 
 primitives to attempt to eliminate the mutex altogether. 
 Nevertheless, we believe that such optimizations are 
 possible.
 "

>  The meaning
> of atomic w.r.t java pointers is or should be well understood, so
> atomic something would be indicated.  Also, it wouldn't preclude
> a non lock-free implementation, though you would lose the bemefits
> of lock-free.
> 
> Maybe atomic_shared_ptr.

Well, I'd love to have a policy-based framework that would 
allow me to specify the *thread-safety policy*:

  thread_safety::unsafe

"naked" count(s)

  thread_safety::basic

pthread_refcount_t stuff ()

  thread_safety::strong

your "atomic" stuff

or something like that. Note that for the blocking stuff, one 
would REALLY want to have some support for priority protocols 
(priority protection or priority inheritance) to fight the 
"unbounded priority inversion" problem in the "realtime" apps.

regards,
alexander.

--
http://terekhov.de/pthread_refcount_t/draft-edits.txt

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

[boost] Re: [lambda] gcc 2.95.2?

[Daniel Frey]

Jaakko Jarvi wrote:
I can't now even get the deque error you mention, can you send me
the error listing (maybe outside of boost list). Maybe there is a better
way to fix it instead of including deque.
The error was exactly what I quoted in the first posting of this thread. 
 The gcc uses a non-conformant deque which has a third parameter, thus 
the forward declaration doesn't work.

Here's the patch for boost/lambda/detail/operator_return_type_traits.hpp:

26a27,37
> // The GCC 2.95.x uses a non-conformant deque
> #if BOOST_WORKAROUND(__GNUC__, == 2) && __GNUC_MINOR__ <= 96
> #  include 
> #else
>
> namespace std {
>  template  class deque;
> }
>
> #endif
>
869d879
<  template  class deque;
Please note that I'm not sure about the status of gcc 2.95.3 or other 
sub-versions, so please someone with more experience have a look at 
this, I'm sure it can be improved :)

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Patches for Borland's free compiler

[David Abrahams]

"Chris Trengove" <[EMAIL PROTECTED]> writes:

>> I don't know that any BCCs can do it.  AFAIK they're all buggy.
>> Someone was working on a port; I think he got pretty far.
>
> I think I am the "someone", and I am fairly sure that no version of BCC will
> compile BP.
>
>> Nope, when I try it, BCC55sp2 chokes on integral constant
>> expressions, as usual.  Some fairly mechanical massage might be
>> enough to make it all work, though.
>
> This is probably the most common error with BCC, and it affects some other
> parts of Boost as well. The compiler is happy if these static integral
> constants are explicitly qualified
>
> template 
> struct Y {
> static const bool value = ...// some test here.
> typedef X::type type; // must have Y::value, not just
> value.
> };

Or if you use the MPL protocol of working with types instead of
integral constants directly.

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

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

RE: [boost] Re: ublas and VC++7.

[Randy Bowen]

> I don't know how good a fix that really is, and for all I
> know it may break other compilers (including VC7.0).
> But it ought at least let you get on with what you're doing,
> until a new release (compiler or library) that fixes
> the problem for real.

Just FYI on the "strict typenames" issues with VC 7.1.  We encountered
this issue in several of our internal libraries, and had to introduce
the 'typename' keyword consistently throughout to get VC 7.1 to compile
properly.  In all of those cases, these changes were backward-compatible
with VC 7.0.  (Sorry -- I can't offer any data on the effect for any
other compilers.)

Randy Bowen
Stamps.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Formal Review: Command Line & Config library

[Pavol Droba]

Hi,

I have tried to use program_options library. I have compiled the library, ran the 
examples and then
incorporated the library into one of my projects.

All worked quite fine.

I have few remarks. 

First and in my opinion the most important one is the matter of documentation.
I find it very hard to use. Examples are quite good to give a nice overview of the 
library
and that's sufficient for a decent start. But searching for the details is quite 
difficult.
I would prefer a few chapters explaining various components of the library, each 
followed by
a reference. Right now I find the documentation rather hard to use. Actuay it is very 
close to
browsing through header files and in my opinion this is not what the documentation 
should
be about.

Besides this issue, I think the library is quite nice and easy to use. 

There are few goodies I'd like to see:

* Arguments

   As it was already mentioned here, arguments should have the same support as 
options. Validation
   and format checking would be appretiated

* Validation
   
   Library allows to supports validation and parsing of option parameters, but I 
thinks it is rather limited.
   It is possible to define user-specific behaviour, but it would be helpful, if some 
common formats
   would be suported. 

   For instance:
  * Various integer types ( not just int ) with boundary checking.
Something like 
   paramter( "count", 1, 4, &count ) // 1-Min and 4-Max value

  * Format specification and checking for string. Regex specification of something 
like scanf would be nice. 
This can be useful for example to check if the parameter is a filename. 

  * Maybe some more 

* Environment & Others

   The library tries to unify the access to program options from command line and from 
ini files. This is very 
   nice feature because it is removing the need for doing generaly the same thing 
twice. 
   It would be nice if some other sources of paramers could be incorporated as well. 
Particulary the enviromnmet
   is often used to exchange arguments. Given the fact that it consist of a set of 
pairs "variable=value"
   it is very similar to the ini file and so it souldn't be hard to implement.

   For windows platform the registry comes to play as another source of options.

Conclusion:

   I think that this library should be ACCEPTED to Boost. However I would strongly 
suggest to put some effort to make
   the documentation more usable.

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

Re: [boost] Comeau/como-win32 regression test results

[Beman Dawes]

At 07:31 AM 5/22/2003, John Maddock wrote:

>>  - Detects some regex problems that previously only Metrowerks was
>>detecting.
>
>Working on it.
Looks like you're making some progress - today's regex tests for Comeau are 
looking better:-)

>> * Shows what looks like a Boost config problem (see date-time 
testclock,
>> for example) which is causing boost::int64_t not to be defined even
>though
>> long long support is present. Help needed on this one!
>
>boost.config looks to be OK (BOOST_HAS_LONG_LONG is defined OK), I'm
>assuming that this may be an issue with the way in which ULONGLONG_MAX is
>defined, but I don't know for certain...

Hum... Yes, that's it!

Here's what it looks like is happening: Como has its own  header 
which #includes .  checks for ULONGLONG_MAX, and defines 
it if not found.

The included version of  is Microsoft VC++ 7.0's, which does not 
define ULONGLONG_MAX.

So far so good.

But then  #includes , so ULONGLONG_MAX isn't 
#defined unless some other header brings it in indirectly.

The fix is to change  to #include . 
That solves the date-time library problems. I'm running the full tests now 
to make sure it doesn't kill any other tests.

Thanks,

--Beman

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

Re: [boost] proposal for efficient geom. vector class

[Matthias Troyer]

In my opinion this proposal should be split into two parts:

1) an efficient container for short fixed size vectors and matrices and 
operations on them, similar to TinyVector in Blitz++. This might 
be part of ublas.

2) a geometry library built on this TinyVector

Matthias

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

[boost] Problems compiling regex with KCC

[Matthias Troyer]

Dear Boosters,

After a cvs update I am having probles compiling cregex.cpp on an Intel 
Linux platform with the KC compiler. The problem seems to be an 
ambiguity in a call to destroy(..). While this is probably a bug in the 
KCC compiler, I would appreciate a workaround (e.g. changing the name 
of the destroy() function in regex) that would make this library 
compile with KCC?

Matthias

Here is the error message:

"/usr/local/apli/KAI/KCC.flex-4.0f-3/KCC_BASE/include/memory", line 
168: error:
  more than one instance of overloaded function "destroy" 
matches the
  argument list:
function template "boost::re_detail::destroy(T *)"
function template "__kai::destroy(T *)"
argument types are: (boost::sub_match *)
destroy(&*first);
^
  detected during:
instantiation of "void __kai::destroy(ForwardIterator,
  ForwardIterator) [with
  ForwardIterator=boost::sub_match 
*]" at
  line 236
instantiation of "ForwardIterator
  std::uninitialized_copy(InputIterator, 
InputIterator,
  ForwardIterator) [with
  InputIterator=boost::sub_match *,
  ForwardIterator=boost::sub_match 
*]" at
  line 285 of
  
"/usr/local/apli/KAI/KCC.flex-4.0f-3/KCC_BASE/include/vec
  tor"
instantiation of "std::vector::vector(const
  std::vector &) [with
  T=boost::sub_match,
  Allocator=std::allocator
  *>>]"



and here the offending part in :

// Modena uses these template function throught the library to help 
clarify things.
// I've placed them in namespace __kai to make it clear that they are 
not for general use.
namespace __kai {
template 
inline void construct(T1* p, const T2& value) { new (p) T1(value); }

template 
inline void destroy(T* pointer) { pointer->~T(); }
template 
inline void destroy(ForwardIterator first, ForwardIterator last) {
for(; first != last; ++first)
destroy(&*first);
}
} // namespace __kai
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] proposal for efficient geom. vector class

[Noah Stein]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn
> Sent: Thursday, May 22, 2003 6:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [boost] proposal for efficient geom. vector class

> As for the point/vector/matrix from a non-graphics point-of-view,
> I agree:
> it should be applicable to any application that makes use of points,
> vectors, etc.
>
> Regarding point = point +/- vector, a vector is a representation of a
> distance (hence why it can be created via point - point), so the above
> operations translate a point by a certain distance. Having point
> = point +/-
> point does not make sence, because a point is a *location* not a
> *distance*.

point = point +/- point might make sense.  It depends upon the vector space
you're using.  In an affine space, you would be correct - you can't add
points together.  Well, even in that space, it can be useful from time to
time: finding the midpoint [(p1+p2)/2] or some other barycentric
combination.  In a Grassman space, any point +/- point combination is a
valid operation.  The paper I referenced in my last e-mail provides a great
discussion of this  very point:

http://portal.acm.org/citation.cfm?doid=504789.504792


-- Noah

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

Re: [boost] Re: [lambda] gcc 2.95.2?

[Jaakko Jarvi]

Hi,

The problems with 2.95 were in bind overloads and deducing function
references, if I remember correctly. However, the bind
overloading was changed at some point for other reasons, and that can have
fixed the trouble.

I can't now even get the deque error you mention, can you send me
the error listing (maybe outside of boost list). Maybe there is a better
way to fix it instead of including deque.

  Cheers, Jaakko


On Thu, 22 May 2003, Daniel Frey wrote:

> I should also mention that I have a patch which solves the problem by
> replacing the forward declaration of deque with a real include in
> boost/lambda/detail/operator_return_type_traits.hpp. Really
> strait-forward. But am interested in the general support of lambda for
> this compiler, as the problem I had will most likely occur for anyone
> using the gcc 2.95.2 immediately and I haven't found any other problem
> after the patch...
>
> Regards, Daniel
>
> --
> Daniel Frey
>
> aixigo AG - financial training, research and technology
> Schloß-Rahe-Straße 15, 52072 Aachen, Germany
> fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
> eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: proposal for efficient geom. vector class

[Jaap Suter]

> It should save some work to define these objects in terms of geometric
> algebra.

While I fully agree with this, you might find you'll have a hard time
convincing other people of this. Many people are so locked into the
traditional concepts of linear algebra that a geometric library without
matrices (to put it bluntly) won't be very useful to many people.

> How about Jaap Suter's Geometric Algebra library?
> http://jaapsuter.com/

If, and only if, people agree that Geometric (or Clifford) Algebra is the
way to go, then my library might be a good starting point. I am still
working on a few issues and adding new functionality (most notably
compile-time versions of the Clifford operators for gradelists, so I can put
a proper operator overloading scheme in place), but the benchmarks I have
done so far prove that my library is the fastest of the few Geometric
Algebra libraries around. One of the things I've done is port the raytracer
(http://carol.wins.uva.nl/~fontijne/raytracer/) made by Daniel Fontijne, and
used as a benchmark for Gaigen and Clu.

I will be releasing a paper with all the details somewhere about 6 weeks
from now. I originally planned to have it done before that, but my work is
taking up too much time at the moment.

If anybody has any questions about my library, I would be glad to help out.
I'm using it a lot myself and it has been very useful so far.

Cheers,

Jaap Suter



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

[boost] Re: Formal Review: Command Line & Config library

[Carl Daniel]

Vladimir Prus wrote:
> Holger Grund wrote:
>> It expands to 13103077 (RTM).
>
> Thanks! BTW, what's "RTM"?

Release To Manufacturing.

-cd



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

[boost] Re: Formal Review: Command Line & Config library

[James Curran]

Chuck Messenger wrote:
>> * add_options() should use references rather than pointers

> "Pointer for return value" is C semantics.  In C++,
> pointers denote optional values.  Non-const references are for return
> values.

I disagree *strongly*.   In C and C++, the address-of syntax clearly
indicates that this is a value that will be changed.  Your suggestion of
using a non-const reference would require me to check the header file to
find the signature of _every_single_F#$^%ing_function to figure out which
parameters are changed and which one's aren't.  (particularly in the case of
add_options() where it would take the causal reader about 10-20 minutes to
find the correct function signature.


>>> * Mandatory options
>>
>> Good idea. Output formatting is the only issue with me.

um... do you think we could start calling this feature "mandatory
parameters" since "mandatory options" is an oxymoron.

-- 
Truth,
James Curran
www.noveltheory.com (personal)
www.njtheater.com (professional)



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

Re: [boost] Re: Formal Review: Command Line & Config library

[Vladimir Prus]

Chuck Messenger wrote:

> >>* Library-managed default values
> >
> > I think it good idea. Need to flesh some details a bit.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Mana
>ged_Default_Values_-_Program_Options_Suggestion
>
> Replace default_value() with optional 3rd arg to parameter(); hardwired
> [...] is fine.

OK, I think we've mostly agreed. See the wiki.

> >>* add_options() should be able to parse arguments (also, %args%)
> >
> > That's a bit controversial. I don't yet see the 100% right approach.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
>Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion

I get your motivation. I'll think about implementation.

> >>* Adaptive formatting (first field width)
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Adaptive_For
>matting_-_First_Field_Width_-_Program_Options_Suggestion
>
> We can't ignore that looks matter.  Ugly won't fly.

The question is: what if first field width is larger than maximum width? What 
can we do? 

> >>* program_name() and %progname%
> >
> > I'm unsure on both of them. See my comments on Wiki
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Name
>_-_Program_Options_Suggestion
>
> Show an example of "hardcoded" program name.

For example: 
options_description desc("Usage: my_program 1.0.1  OPTIONS\n"
 "OPTIONS");


> >>* Unified exception class
> >
> > I think such class exists already.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Unified_Exce
>ption_Class_-_Program_Options_Suggestion
>
> OK, but change exception name from "error" to "program_options_error"

I'm almost indiffirent and will be happy to leave this question to others.

> >>* Put add_options() ascii args first
> >
> > It's completely up to reviewers.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
>Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion
>
> >>* Mandatory options
> >
> > Good idea. Output formatting is the only issue with me.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Mandatory_Op
>tions_-_Program_Options_Suggestion
>
> I like your format.

Great! We've agreed.

> >>* Optional "option present" parameter to add_options()
> >
> > I'd like to see some use cases before adding this feature.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Optional_Opt
>ion_Present_Parameter_To_Add_Options_-_Program_Options_Suggestion
>
> E.g., "grep -f file" -- we want file name, and "pattern-in-file" mode

I understand your motivation now, and need only decide on exact interface. 

> >>* add_options() should use references rather than pointers
> >
> > That's style issue, and I'm not partial. Let's hear other opinions.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
>Should_Use_References_Rather_Than_Pointers_-_Program_Options_Suggestion
>
> I don't agree.  "Pointer for return value" is C semantics.  In C++,
> pointers denote optional values.  Non-const references are for return
> values.

Ehm... the "pointer for return values" rule is from TC++PL, IIRC.

> >>* User exception
> >
> > If you have practical need to them, I'll add them.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?User_Excepti
>on_-_Program_Options_Suggestion
>
> No - this was just a workaround for lack of integrated argument processing.

OK.

Thanks again for such a comprehensive review!
- Volodya


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

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

RE: [boost] proposal for efficient geom. vector class

[Joshua Napoli]

It should save some work to define these objects in terms of geometric
algebra.

How about Jaap Suter's Geometric Algebra library?
http://jaapsuter.com/


-Joshua


-Original Message-
[...]
i suppose it would be neat to have boostified vectors
as we have boostified quaternions, octonions, etc.

so what about this idea?

respect,
Justinas V.D.
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


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

Re: [boost] proposal for efficient geom. vector class

[Reece Dunn]

Some brief thouhgts from the various comments. (Sorry if I dont credit you, 
I am a bit bust at the moment).

There are many libraries available that are aimed at solving these problems 
(uBlais, Blits++, MTL and others). The problem is that these are not 
standardized, are generally non-portable (as was mentioned), are usually 
specific (e.g. over choice of number representation), and may be hard to 
integrate with the STL and other areas of the standard.

Having a geometric library and a matrix library that are Boostified would 
make a program more portable, since there would not be a need to install a 
specific framework such as MTL. Also, the Boostified version would make it 
easier for the programmer to develop programs using geometric constructs, as 
they would not need to learn many variants of the same construct.

As for the point/vector/matrix from a non-graphics point-of-view, I agree: 
it should be applicable to any application that makes use of points, 
vectors, etc.

Regarding point = point +/- vector, a vector is a representation of a 
distance (hence why it can be created via point - point), so the above 
operations translate a point by a certain distance. Having point = point +/- 
point does not make sence, because a point is a *location* not a *distance*.

Also, I said that this was an initial idea, so the cross/dot product issue 
will need thinking about. Also, the standard library has an inner_product 
function.

The matrix functions was not meant to be complete. I agree that there should 
be an inverse function, also an adjoint function.

point2D boost::geometric::project( point2D )
That was a typo, it was meant to be:
  point2D boost::geometric::project( point3D )
to aid with rendering of 3D objects. There also needs to be 4D -> 3D to 
render objects such as tesseracts (4D cubes!) on the screen. I do not know 
anything about affine transforms, but they look useful.

I would need to do more research into the mathematics to create a library 
like this.

As has been mentioned, there is the need for other geometric constructs, 
such as planes, conics and so on.

Regards,
Reece
_
On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: [lambda] gcc 2.95.2?

[Daniel Frey]

I should also mention that I have a patch which solves the problem by 
replacing the forward declaration of deque with a real include in 
boost/lambda/detail/operator_return_type_traits.hpp. Really 
strait-forward. But am interested in the general support of lambda for 
this compiler, as the problem I had will most likely occur for anyone 
using the gcc 2.95.2 immediately and I haven't found any other problem 
after the patch...

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [lambda] gcc 2.95.2?

[Daniel Frey]

Hi,

I was finally able to upgrade our company's boost installation from 
1.25.1 to 1.30.0 last week :)) I happily tried to use it, but I ran into 
a small problem: The compiler we are using is still the gcc 2.95.2 with 
no chance for an upgrade in the foreseeable future. When I included 
boost/lambda/lambda.hpp, I got:

/usr/include/g++/stl_deque.h:480: previous declaration `template , unsigned int __bufsiz = 0> 
deque<_Tp,_Alloc,__bufsiz>'
../../release/include/boost/lambda/detail/operator_return_type_traits.hpp:869: 
used 3 template parameters instead of 2

Is this expected? The docs say, that the lambda-lib is supposed to work 
for the gcc 2.96, so what's required to use it with the gcc 2.95.2? Or 
isn't it possible at all because the compiler is simply too old?

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: proposal for efficient geom. vector class

[Patrick Kowalzick]

Hi Justinas,

do you mean something like this? Please regard code below.

Using the second parameter of the template arguments to define the size of a
vector, so that you can call specialized functions for the right dimension?

Greets,
Patrick

// ***
template 
class vector {
 public:
  T& operator[](const size_t& pos) { return v[pos]; }
  const T& operator[](const size_t& pos) const { return v[pos]; }
 private:
  T v[s];
};

void cross(vector &vr,
 const vector &v1,
 const vector &v2) {
 vr[0]= v1[1]*v2[2]-v1[2]*v2[1];
 vr[1]=-v1[0]*v2[2]+v1[2]*v2[0];
 vr[2]= v1[0]*v2[1]-v1[1]*v2[0];
}

// Point
// no partial specialization due to MSVC 6.0
template 
class point {};

template <>
class point : public vector {};
template <>
class point : public vector {};

// Line
template 
class line {};

template <>
class line : public vector {};

template <>
class line : public vector {};

// Plane
template 
class plane {};

template <>
class plane : public vector {};

// join-function
void join(line& l,
const point &p1,
const point &p2)
{
 cross(l,p1,p2);
}

void join(point& l,
const line &p1,
const line &p2)
{
 cross(l,p1,p2);
}

template 
std::ostream& operator<< (std::ostream& ostr,vector v) {
 for (std::size_t i=0;i p1,p2,p3,p4;
 p1[0]=0;p1[1]=0;p1[2]=1;
 p2[0]=2;p2[1]=2;p2[2]=1;
 p3[0]=2;p3[1]=0;p3[2]=1;
 p4[0]=0;p4[1]=2;p4[2]=1;
 std::cout << p1 << std::endl;
 std::cout << p2 << std::endl;

 line l1,l2;
 join (l1,p1,p2);
 join (l2,p3,p4);
 std::cout << l1 << std::endl;
 std::cout << l2 << std::endl;

 point ps;
 join (ps,l1,l2);
 std::cout << ps << std::endl;
}
// ***

"jvd" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> hello boosters,
>
> subject tells itself about the thing i'm going to
> propose.
>
> AFAIK, there're no vector (i mean
> geometrical vectors) classes in boost
> (well, there's uBLAS version of vectors but that's rather a container
> than a geometrical primitive, correct me if i'm wrong).
>
> idea itself is borrowed from blitz++.
>
> template< typename T, std::size_t N >
> class tiny_vector { /**/ };
>
> vector operations are and should be implemented
> inlinely. there should be no inner loops in additions
> substractions, scalar multiplication/division, etc.
>
> i suppose it would be neat to have boostified vectors
> as we have boostified quaternions, octonions, etc.
>
> so what about this idea?
>
> respect,
> Justinas V.D.
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>



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

[boost] sequence_array contribution

[Maarten Hilferink]

Dear Boosters,

(questions regarding contributing to boost at the end of this mail)

I have made a:

template struct sequence_array;

which has an interface that is almost compatible with

std::vector >;

but faster.

Rationale:

I often worked with vectors of sequences, two examples:

1. typedef std::pair dpoint;
typedef std::vector dpolygon;   // point sequence
typedef std::vector dpolygon_array; // point sequence array

2. typedef std::basic_string String; // char sequence
typedef std::vector StringArray; // char sequence array

When working with vector-based sequence arrays (as above),
I found that the implementations are not efficient
due to the many allocations/deallocations of the individual sequences.
Especially the destruction of such vector based sequence arrays
often takes unneccesary and annoying amount of time.

Since the lenght of the individual sequences is often higly diverse,
an implementation based on two dimensional
arrays with fixed row lengths was not an option.

Therefore I have implemented:

template struct sequence_array;

that uses an internal
std::vector m_Data;
for sequencial storage of sequences of T
and an additional
std::vector > m_Seqs;
for identifying allocated sequences.

sequence_array offers typedef iterator, const_iterator, reference, and
const_reference
with interfaces nearly compatibe with
std::vector*, const std::vector*, vector&, resp. const vector&.
(the sequences however don't have a reserve() member function,
only a resize() resulting in reallocation in m_Data if they grow
AND [are not the last sequence in m_Data
or insufficent reserved space after m_Data.end() is available] )

he storage m_Data grows with the familiar doubling strategy
as sequences are inserted or re-allocated due to calls to their resize() mf.
m_Seqs is adjusted when m_Data has grown by re-allocation.

Destruction of a sequence_array only requires two calls to delete[].
(assuming that T::~T() doesn't do additional things).

sequence_array minimizes the pollution of the heap with varying sized
arrays.

Users benefit most when the total size and number of the sequences is known
in advance,
and provided to a sequence_array by the member-functions reserve() and
data_reserve().

For the discussion, I have made my pre-boost facilities library available
at:
http://www.objectvision.nl/dms/downloads/rtc-src-2003-05-21.zip
It contains the file GeoSequence.h, which contains the
template  struct SequenceArray;

At this point, my implementation is not ready for inclusion in boost for the
following reasons:
- it is dependent on other headers in my pre-boost facilities library
- it is not yet in boost style
- lack of required peer review in order to get sufficient quality and
general purpose usability.
(however, it does work fine after having solved some problems in our
product).
- open design issues

I specifically would like to hear from you on the following design issues:
- I am considering to change the definition of the above mentioned m_Seqs
to:
std::vector > m_Seqs;
where m_Seqs[i].first and second are offsets of the start and end of
sequence i relative to m_Data.begin().
This avoids adjustment when m_Data grows, for a small const access-time
penalty.
- At this point, the destruction of abandoned elements in m_Data
 (= elements not being part anymore of a reallocated sequence),
 is deferrred to the destruction or re-allocation of m_Data.
- the last sequence in m_Data now gets special treatment when it is resized
and sufficient reserved
space is available after m_Data.end(). This special treatment saves an order
of complexity
when the last sequence often grows, but adds a constant cost to the
re-allocation administration.
- generalization to sequece_array arrays (3 levels deep) or higher
dimensions.
(this would require more intelligent template definitions than I have now)

I am willing to spend some time to make sequence_array boost ready,
but only if it is considered useful.

I therefore have the following questions:

1. Arye you interested in such contribution?
2. Is a similar construct already in boost or is it being considered?
3. Do you know of other solutions for efficient management of
sequence_arrays?
4. Is my assumtion true that the above described behaviour could not have
been created
by using a smart allocator as a second template argument to std::vector?
(I assumed this since allocators cannot have a vector instance specific
state)
5. any design suggestions?
6. could somebody with more experience with contributing to boost mentor me
with making a sequence_array contribution ready?


Regards,
Maarten Hilferink
[EMAIL PROTECTED]


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