date:20030602

Stefan Seefeld wrote:

What I originally suggested was not a parser, but a set of APIs to
manipulate XML. The parser part (i.e. the piece of code that generates
a parse tree from an XML file) is the simples part of it all. What
is much more tricky is to get the right internal structure to make
operation on the tree efficient and convenient.

That said, I would *not* recommend to rewrite any such thing. It is
a *lot* of work, and as such quite unrelated to boost's goals.
Would also mapping an implementations structure to a C++ internal structure 
also require quite a bit of work?

OPTION 1: C++ specific internal mappings.

boost::xml::dom::document doc( "demo.xml" );

class document
{
  private:
 boost::xml::dom::element root;
  public:
 document( const char * fn )
 {
impl::XMLDOMDocument doc( fn );
BuildXMLDOM( doc.documentElement, root );
 }
  private:
 void BuildXMLDOM( impl::XMLDOMElement, boost::xml::dom::element & );
};]
Where BuildXMLDOM recursivley builds the internal XML tree structure.

NOTE: This is necessary if you want to use an internal C++ representation to 
efficiently model the structure for C++ bindings, e.g. using trinary search 
trees or other associative container for attribute storage.

This would make the loading of an XML document more computationally and 
memory intensive because you have to load it twice (one by the parser and 
one by the C++ bindings). There are problems in this regard when loading 
large documents (effectively having double the memory capacity). Also, what 
about SAX facilities?

OPTION 2: If you are intending to wrap an implementation like libxml2 into a 
C++ interface, you would sacrifice how the data is represented internally 
and you would get a slight performance penalty from the wrappers (not so 
much if you use inlined functions). This approach would not suffer the 
loading penalties described above.

OPTION 3: Writing a boost XML/XPath parser would allow the internal 
structure to be optimised for C++-specific bindings, while not suffering 
from either wrapper performance penalties nor document loading/SAX parsing 
penalties.

What I had (and still have) in mind is a C++ interface to an existing 
implementation (libxml2 actually).
What if the user wants an interface to another implementation? Is it 
possible to standardize access to other parsers.

NOTE: If you are using the option 1 approach, the variations would occur in 
boost::xml::dom::document - specifically the constructor and the semantics 
for BuildXMLDOM.

Also I'm not convinced that the main goal should be to conform with
the DOM specs as provided by w3c. Lots of implementers / users consider its 
design broken. Instead I'd suggest to try to come up with a 'good' C++ API, 
and then build a wrapper around it that provides the legacy
mapping as needed.
This is the thinking that I have moved towards, more details of which can be 
found in my last post on the subject.

NOTE: Here and in my previous post, I use DOM to refer to the C++ Document 
Object Model binding, and not the W3C DOM standard. when I refer to that, I 
use the W3C to specify what type of DOM it is.

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

Re: [boost] RE: an XML API in boost

2003-06-02 Thread Stefan Seefeld

Reece Dunn wrote:

[1]  It should make use of the Spirit and Regex libraries for XML and 
XPath parsing.
note that parsing is only a small part of it. A dom-like API for example
needs heavy support from the internal structure for things like 
namespace, entity, node (xpath) lookup, etc.

[2]  It should conform to the following W3C standards:
  (a)  XML 1.0 SE while looking at supporting XML 1.1 in the future;
yes

  (b)  DOM 1.0/2.0/3.0
I would argue about that. these specs are considered broken in many
ways. Also, they are not particularly 'C++ friendly'. I'd start with
a 'C++ API' that really fits into the language (and surrounding libs
such as libstdc++ or boost), and then provide API mappers on top of
that to conform to whatever people need/want.
  (c)  XPath 1.0 with XPath 2.0 support in the future (switch between 
them??)
yes

  (d)  Unicode 3.x support (I know this is not a W3C standard, but it is 
related)
I'd argue that XML and unicode are quite unrelated (read: orthogonal).
Let me explain: I have been proposing to wrap an existing xml library,
which deals with the i/o. The internal representation is utf-8
('char *'). The XML API I actually provide through my wrapper is 
DOM-like tree manipulation, node lookup (XPath), reading/writing,
and of course a SAX-like API.
None of this requires direct unicode functions. That's why I 
parametrized the code for specific string types, so the user can
'plug in' his own string types and let them do the work. No need to
make the XML API more feature-rich than it needs to be.

while these standards would be useful to have support for:
  (e)  XSLT 1.0 with XSLT 2.0 support in the future (select which to use?)
nice-to-have, but not really necessary for a xml library.

  (f)  XMLSchema 1.0
yes

these standards are optional, but should be implementable using the base 
standards:
  (g)  XSL:FO 1.0
  (h)  MathML 1.0/2.0
  (i)  SVG 1.x/2.x - Scalable Vector Graphics

NOTE: The library should be capable of evolving as the web standards 
evolve.
That's a lofty goal. :-)

[3]  It should have W3C DOM bindings for the XML document in a way that 
allows support for adding extensions to this, e.g. providing a MathML or 
SVG DOM on top of the XML DOM.
yeah, probably on a wrapper layer on top of the 'core'.

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

Re: [boost] Re: an XML API in boost

2003-06-02 Thread Stefan Seefeld

What I originally suggested was not a parser, but a set of APIs to
manipulate XML. The parser part (i.e. the piece of code that generates
a parse tree from an XML file) is the simples part of it all. What
is much more tricky is to get the right internal structure to make
operation on the tree efficient and convenient.
That said, I would *not* recommend to rewrite any such thing. It is
a *lot* of work, and as such quite unrelated to boost's goals.
What I had (and still have) in mind is a C++ interface to an existing
implementation (libxml2 actually).
Also I'm not convinced that the main goal should be to conform with
the DOM specs as provided by w3c. Lots of implementers / users consider
its design broken. Instead I'd suggest to try to come up with a 'good'
C++ API, and then build a wrapper around it that provides the legacy
mapping as needed.
Kind regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: boost:program_options use case and review

2003-06-02 Thread Vladimir Prus

Hi Misha,

Misha Bergal wrote:

> I have 2 use cases for program options library. I would say that they are
> fairly advanced but nevertheless typical ones:
> Due to severe time constraints I am going to describe just the first use
> case, which I think will highlight significant number of
> boost::program_options benefits and problems .

Thanks for finding the time for review!

> - USE CASE -
> 1. Program options of Perforce version control "p4" client.
> p4 program options come from (in the order of descending priority)
> 1. Command line
> 2.standard  input
> 3. config file
> 4. Windows registry
> 
> 1. The command line has the general format:
> p4 [global-options]  [command-options]
[...]
> Please note, that "-c" option has semantic is different between
> global-options and command options

While I don't think such difference in semantic makes good UI, I won't argue
this point here. A little bit later, I'll consider how to support it, as
well as support options with the same meaning everywhere.

> 2.Describe options
> 
>  global_options_desc.add_options()
>   ( "c", parameters( "", &go.client ), "some comments here"  )
>// Problem #1.
>// The first parameter is a mini-language. Usually C++ tends to
>avoid
> minilanguages.
>// For example: iostreams don't use "w+", "rw", "a", although
> iostreams are not always
>// the example of practices to follow.
>// Still, for users minilanguage might be unexpected here

I disagree. For iostreams, all those flags are not used all that often. For
program_options they are likely to be present quite often.

>// Note: need to make sure that parameter can take optional<>

Good point. Added to todo.

>  3. Read - lowest priority first
> 
>  // 3.1. Read registry and config file
>  // Problem #2 - the names in the registry and config file are not the
>  same
> as the names given in options_description

Yep. It was noted by Gennadiy already, and I'm considering where to add
remaning facility. As you've mentioned in use case description above, the
names in config file can actually be derived from command line names.

>  // --- custom written ---
> mtn::copy( config_file( ".p4config" ), inserter( go ) ); // insert options
> in go (variables_map, or lexical_map)
>  // --- end custom written ---

I assume "mtn::copy" works with containers, right? Still, for this to work,
"config_file" must be container which value_type is something more fancy
than string, while I'd prefer it to be purely syntax parser.

>  // 3.2. Read command line
>  // 3.2.1 Separate global options from command options
>  options_and_arguments oa = parse_command_line(argc, argv, desc);
>  // Problem #3: Would be nice if options_and_arguments was a  sequence
>  command_options_and_arguments = mtn::find_if( options_and_arguments,

I guess the variable declared should be called "command"? Else I don't
understand what's 'command' in the line below.

> &is_argument );
>  global_options_and_arguments  = mtn::iterator_range(
> options_and_arguments.begin(), command.begin() );

I think there are some problems here. In order to parse subprogram options,
you need to register them. Else, how the parser is to tell if "-c foo" is
a option with value, or an options without value and an argument? But you
cannot register subprogram options, for example becuse "-c" is both global
option and a subcommand option.

So, you have to stop parsing options on the first argument, and assume all
other tokens are arguments. I.e. add a style option which tells that
non-options token ends arguments. If such facility is added, then subcommand
options are retrievable via options_and_arguments::arguments() method.

You can pass them to subcommand which can declare it's own
options_description instance (which can include "-c" with different
meaning), and parse it.

Imagine a different approach: all options mean the same everywhere. Some
subcommands however, don't use certain options. Ok, we'll have

   options_description desc()
// declare all options
;

   options_and_arguments oa = parse_command_line(..., desc, ...);
   std::string subcommand = oa.arguments()[0];
   std::set allowed = allowed_options[subcommand];
   // validate that all options are allowed for this subcommand.

   // everything else is as usual.

So, the added complexity is declaring list of options that each subcommand
takes, and a small loop to do checking.

>  // 3.2.2. Find out whether I need to read a rest of arguments from
>  standard
> input
>  // Problem #4: Seems that it is too late to ask boost::program_options to
> do that
>  // May be the arguments need to be read from stdin and the command line
> parsed again?

Yes, I think that's the right way. In fact, it's how response files can be
supported. Hartmut Kaiser already used this approach in Wave and I was
planning to add such support, but haven't yet.

> 
>   // 3.2.3 Store global_options

Re: [boost] Re: an XML API in boost

2003-06-02 Thread Larry Evans

Reece Dunn wrote:
Anthony Williams wrote:

> Writing an XML parser from scratch for boost should, IMHO, have these
> features:
[snip]

Writing a lexer/parser is a complex task. It wasn't a requirement, more 
a suggestion/my opinion on what a boost XML library should be like. 
There are four possible options:

[snip]

[4] Use another lexer/parser generator. This is an unknown, and again 
with the Boost distribution.
I'd suggest pccts or antlr:

  http://www.antlr.org

It can generate c++ code.  IIRC, it has good error recovery, which is 
something SPIRIT is a bit weak in.

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

Re: [boost] Re: Preliminary submission: Finite State Machineframework

Reece,

> >Unfortunately, I don't have much experience with anything else
> than MS
> >compilers. I will try to port to gcc, but I'll probably need help
> for
> >not-so-conforming compilers like Borland.
> 
> I have experience with GCC, MS and Borland if you need help porting
> the 
> code.

Cool, I could probably use some help with the gcc-port in about a
month or so. Borland could follow.

> >[snip]
> >void Pump::Start()
> >{
> >initiate< Idle >(); // * here *
> >}
> 
> Wouldn't this complicate the code that the programmer has to write,
> whereas 
> your version was simpler to implement. (Just my opinion).

True. After posting I realized that the current design already allows
you to hide the states in the .cpp file anyway. All that remains in
the .hpp is one forward declaration of the initial state. The above
approach is only necessary if you want to hide that as well. I guess
most people wouldn't bother.

> >Does the library/code generator you're currently using work with
> >polymorphic events? Is not having polymorphic events a showstopper
> for you?
> >If yes, I would be interested in a as-real-world-as-possible
> example.
> 
> I'm not sure on this, but would Windows-based code that redirects
> events to 
> a Window class be a polymorphic event, e.g.
> 
>class WindowBase
>{
>   public:
>  virtual void Paint( win::api::DC & hDC );
>  // ...
>};
>class MyGUIWindow: public WindowBase
>{
>   public:
>  void Paint( win::api::DC & hDC ); // custom window
> graphics
>};
> 
> Not sure how you would integrate this with a FSM though!

AFAICT, WindowBase and MyGuiWindow objects are both state machines
producing different reactions for the same Paint event, which is
therefore not polymorphic.
A state machine supports polymorphic events, only if ...
- Events can derive from each other without restrictions (see
Bohdan's MouseEvent example)
- You can specify reactions for nodes as well as leaves of the event
inheritance tree. That is for MouseEvent, MouseDownEvent and
MouseUpEvent in Bohdan's example.

Thanks for the feedback!

Regards,

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

Re: [boost] Re: Preliminary submission: Finite State Machineframework

Reece,

> >Unfortunately, I don't have much experience with anything else
> than MS
> >compilers. I will try to port to gcc, but I'll probably need help
> for
> >not-so-conforming compilers like Borland.
> 
> I have experience with GCC, MS and Borland if you need help porting
> the 
> code.

Cool, I could probably use some help with the gcc-port in about a
month or so. Borland could follow.

> >[snip]
> >void Pump::Start()
> >{
> >initiate< Idle >(); // * here *
> >}
> 
> Wouldn't this complicate the code that the programmer has to write,
> whereas 
> your version was simpler to implement. (Just my opinion).

True. After posting I realized that the current design already allows
you to hide the states in the .cpp file anyway. All that remains in
the .hpp is one forward declaration of the initial state. The above
approach is only necessary if you want to hide that as well. I guess
most people wouldn't bother.

> >Does the library/code generator you're currently using work with
> >polymorphic events? Is not having polymorphic events a showstopper
> for you?
> >If yes, I would be interested in a as-real-world-as-possible
> example.
> 
> I'm not sure on this, but would Windows-based code that redirects
> events to 
> a Window class be a polymorphic event, e.g.
> 
>class WindowBase
>{
>   public:
>  virtual void Paint( win::api::DC & hDC );
>  // ...
>};
>class MyGUIWindow: public WindowBase
>{
>   public:
>  void Paint( win::api::DC & hDC ); // custom window
> graphics
>};
> 
> Not sure how you would integrate this with a FSM though!

AFAICT, WindowBase and MyGuiWindow objects are both state machines
producing different reactions for the same Paint event, which is
therefore not polymorphic.
A state machine supports polymorphic events, only if ...
- Events can derive from each other without restrictions (see
Bohdan's MouseEvent example)
- You can specify reactions for nodes as well as leaves of the event
inheritance tree. That is for MouseEvent, MouseDownEvent and
MouseUpEvent in Bohdan's example.

Thanks for the feedback!

Regards,

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

[boost] IO Formatting Manipulators

Does anyone have any ideas/suggestions:
*  on where I should extend the code
*  what features they would like to see that are not currently available
*  bugs/inconsistencies with existing features
I would also like to have comments on what people want out of the 
documentations. Whether they want:
*  a technical description of the facilities
  *  an 'under the hood' look at the implementation
*  standardese description of the classes
*  detailed examples of how to output a given type
*  organisational ideas (e.g. separate the tutorial from the main section)
*  rationale for the various design choices
*  other features

NOTE: Because I have revised the main code, I am looking at overhauling what 
documentation I had. The documentation is high on my to do list, but I have 
not started it yet as I have been busy. I should start it on Wednesday.

All feedback would be very welcome.

PS: Here is a link to the latest version in case you missed it.
  http://lists.boost.org/MailArchives/boost/msg47757.php
Regards,
Reece
_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] type_traits webpage error

2003-06-02 Thread Mike Conley

The type_traits webpage contains the following, from which 
is_base_and_derived should be removed:


>Note that both is_convertible, and is_base_and_derived can produce 
>compiler errors if the convertion is ambiguous:
>
>struct A {};
>struct B : A {};
>struct C : A {};
>struct D : B, C {};
>bool const x = boost::is_base_and_derived::value;  // error
>bool const y = boost::is_convertible::value; // error

--  
Mike Conley


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

Re: [boost] Re: an XML API in boost

Anthony Williams wrote:

> Writing an XML parser from scratch for boost should, IMHO, have these
> features:

> [1] It should make use of the Spirit and Regex libraries for XML and 
XPath
> parsing.

Whilst these libraries might be useful for the parser writer, I don't see 
any
benefit to requiring their use for a boost XML parser. If a submitted 
parser
used alternative parsing methods that should be acceptable provided it 
worked.
Writing a lexer/parser is a complex task. It wasn't a requirement, more a 
suggestion/my opinion on what a boost XML library should be like. There are 
four possible options:

[1]  Write the lexer-parser by hand. This is a difficult process to get 
right, and can lead to complex code that is difficult to update.

[2]  Use flex/bison or equivalents. These are C-based lexers and as such, it 
is difficult to integrate with C++ (especially since several implementations 
use K&R C and make use of variables called class!!). Also, do we then 
require that flex/bison be distributed with Boost??

[3] Use Boost.Spirit/Boost.Regex. These are written in C++ and so make use 
of advanced techniques. For example, the use of templates make writing the 
parser as easy as writing BNF grammars! Also, Spirit uses 
trinary-search-trees that have very fast lookup as an associative-style 
container. Also, using these libraries will prevent wheel reinvention and 
make the code more boostified.

[4] Use another lexer/parser generator. This is an unknown, and again with 
the Boost distribution.

> [2]  It should conform to the following W3C standards:

>(b)  DOM 1.0/2.0/3.0

Hmm. The DOM standards in particular are very Java oriented, and don't
necessarily make for efficient C++ bindings. I can see that the parser 
needs
to provide the same set of facilities though, even if it is done in a
different way.
If you are writing a program that interacts with XML via a scripting 
language, then DOM bindings would be needed (especially if you are wanting a 
browser that can, for example, control SVG objects when the user interacts 
with them). I know that this could be done using the MS parser, but what if 
you wanted good unicode support for something like MathML?

I also agree that efficient C++ bindings would be very desirable. What about 
a C++-to-DOM binding wrapper?
  e.g. boost::w3c::dom::DOMElement< boost::xml::element >
NOTE: This is just a suggestion. That way, you can make the C++ versions 
very efficient, while the DOM versions will have a wrapper layer to them.

IMHO, the base parser should provide an API on which other things can be
built. For example, provided the facilities are present to retrieve the
information needed for XPath processing, the core API doesn't need to have 
an
XPath processor. Likewise for XSLT.
Agreed. XML, DTD and XPath parsing and structure navigation with unicode 
support are all that is required for the base level. That is why I put the 
others as optional. It would be nice if the library supported XPath 
navigation, XSLT, and DTD/XMLSchema validation, though as these are common 
facilities.

However, I think it is important that the library does include add-on APIs 
for
as much of the supporting standards as possible, such as DOM-like 
processing,
XPath node selection, DTD and XMLSchema validation, and XSLT.
Agreed. Perhapse it would be best to organise accoring to facilities:

  boost::xml::dom -- C++ DOM bindings
  boost::w3c::dom -- W3C DOM bindings (requires boost::xml::dom)
  boost::xml::xpath -- XPath parsing/navigation
  boost::xml::xslt -- requires boost::xml::dom and boost::xml::xpath
  boost::xml::xslfo -- requires boost::xml::xslt
  boost::xml::mathml -- requires boost::xml::dom
  etc.
This way, the user can include which API's he/she wants with minimal 
dependencies.

> [4] It should provide XPath bindings to the XML DOM in a clean way; I
> personally like the MS selectSingleNode/selectNodes extension to the XML
> node DOM interface.

There is no point in providing XPath support if it's painful to use.
I was thinking in terms of a W3C DOM. If we are thinking in terms of C++ 
bindings, the usage could be like this:
  boost::xml::dom::node root;
  // ...

  // select a single node - note usage of array-style notation:
  boost::xml::dom::node sel = root[ boost::xml::xpath::expr( L"/*[1]" )];
  // select a collection of nodes - can accept an XPath string or XPath 
expression
  boost::xml::xpath::result_set math( root, L"//m:math" );

This would give a cleaner interface between XML and XPath. (NOTE: I have 
implemented this style of syntax for my MS-XML wrappers).

> [5] It should have a clean access to attributes, without the user 
needing to
> call get/set methods.

I am not sure what you mean here.
I was thinking from a W3C DOM/MS COM PoV where the attributes are 
implemented via get and set methods [Example:
  get_documentElement( IXMLDOMNode * )
vs
  XMLDOMNode XMLDOMDocument.documentElement
], but with clean C++ bindings this is largely irrelevant.

I am

[boost] Re: Better Intel-Win32 support

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 03:09 PM 6/1/2003, David Abrahams wrote:
>  >"Pavel Vozenilek" <[EMAIL PROTECTED]> writes:
>  >
>  >> "Beman Dawes" <[EMAIL PROTECTED]> wrote in message
>  >> news:[EMAIL PROTECTED]
>  >>>
>  >>> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being
>  set. I'm not
>  >> so
>  >>> worried about ADL, at least with VC++ <7.1.
>  >>>
>  >> You may look on test table
>  >> http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.
>  >
>  >I'm not sure what I should expect to get out of that.  In order to
>  >make the toolset changes work, when I turn on wchar_t support I also
>  >define _NATIVE_WCHAR_T_DEFINED on the command-line, so it all works
>  >out.
>
> That will certainly work, but you shouldn't have to do that since the
> compiler itself defines _WCHAR_T_DEFINED. 

_WCHAR_T_DEFINED is no help at all in getting full wchar_t support if
the standard library (Dinkumware) doesn't detect it.  See the 
header, for example.  It only checks for _NATIVE_WCHAR_T_DEFINED.

> Since I made the fix earlier this afternoon I am able to compile
> some non-boost code correctly which had previously be failing.

What fix is that, and did the code use iostreams or limits?

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

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

[boost] Re: boost:program_options use case and review

"Misha Bergal" <[EMAIL PROTECTED]> writes:

> It seems to be important to support the handling of this syntax style,
> because:
> 1. It seems to be very "widespread", meaning the number of people, not
> necessarily the number of products.

That seems to be the cvs style, also, FWIW.

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

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

[boost] Re: Better Intel-Win32 support

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 02:50 PM 6/1/2003, Pavel Vozenilek wrote:
>
>  >
>  >"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
>  >news:[EMAIL PROTECTED]
>  >>
>  >> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being
> set. I'm not
>  >so
>  >> worried about ADL, at least with VC++ <7.1.
>  >>
>  >You may look on test table
>  >http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.
>  >
>  >(Warning : when playing with options I managed to break something in
>  >compiler configuration and as result compiler decided to define macro
>  >indicating wchar_t support _always_.)
>
> I've made the fix as you indicated. If that isn't right, let me know.

What fix did you make?

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

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

RE: [boost] 1.30.0 RPMs

2003-06-02 Thread Malte Starostik

On Monday, June 02 Rene Rivera wrote:
>[2003-06-02] Malte Starostik wrote:
>
>
>>In order to save some time downloading you can as well:
>>* get only boost-jam.spec and boost.spec from the URL above
>>* get the boost sources from boost.org (tar.bz2 version, not tar.gz)
>>* copy tools/build/jam_src/ somewhere else and rename it to
>boost-jam-3.1.4/
>>* from the boost-jam-3.1.4/'s parent dir, run tar -cf 
>boost-jam-3.1.4.tar 
>>boost-jam-3.1.4/ && bzip2 boost-jam-3.1.4.tar and copy the resulting
>bzip2ed 
>>tarball to the SOURCES subdir of your rpm root directory.
>>* build boost-jam with rpm -bb boost-jam.spec and install it
>
>OK, that seems rather arduos when you can just:
>
>cd $BOOST_ROOT/tools/build/jam_src
>sh ./build.sh --- dist
>
>Then install the resulting RPM(s).
>
>Any reason why you don't use that instead? Or for that matter 
>use the RPM in
>the SourceForge files distribution section?

For build.sh, because I didn't know about it, for the ones from SF,
can't remember what exactly but I had some problems with those in the
past.
One thing I don't like about the .spec file inside jam_src is that it
only works when rpm is invoked with some additional environment vars
set, basically intended for invokation via jam. IMHO a .spec file
shouldn't require this and build fine with rpm -b[abcips] or rpm
-t[abcips]
But thanks, I'll try them again.

-Malte

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

[boost] boost:program_options use case and review

2003-06-02 Thread Misha Bergal

I have 2 use cases for program options library. I would say that they are
fairly advanced but nevertheless typical ones:
Due to severe time constraints I am going to describe just the first use
case, which I think will highlight significant number of
boost::program_options benefits and problems .

- USE CASE -
1. Program options of Perforce version control "p4" client.
p4 program options come from (in the order of descending priority)
1. Command line
2.standard  input
3. config file
4. Windows registry

1. The command line has the general format:
p4 [global-options]  [command-options]

where global options are:
-c client
-d dir
-G
-H host
-p port
-P pass
-s
-u user
-x file
-C charset
-L language
-V
-h

and command-options depending on command. For example the command "submit"
has the following possible options

p4 [g-opts] submit [-r] [-s] [files]
p4 [g-opts] submit [-r] -c changelist#
p4 [g-opts] submit -i [-r] [-s]

Please note, that "-c" option has semantic is different between
global-options and command options

2. The arguments can be read directly from the standard input, in this case
they should be separated by newline character.
3. The config file has the structure
P4=value
for example, instead of specifying option "-c myclient" in command line,
user can write
P4USER=myclient
4. The "most default" values are stored in Windows registry in format
similar to config file.
- END OF USE CASE -
It seems to be important to support the handling of this syntax style,
because:
1. It seems to be very "widespread", meaning the number of people, not
necessarily the number of products.
2. It is structurally complicated enough to break the simplistic
implementation.

I will try to iteratively go through implementation, highlighting the
problems and helpful features, soliciting library author feedback on the
way.

- IMPLEMENTATION (PSEUDOCODE) ROUND 1 --

1. Options storage

variable_map go; // global_options

or
struct global_options
   {
   boost::optional client; // Need optional
   boost::optional dir;
   bool   pythonize;
   bool   show_version
   
   };

global_options go;

or  may be?
lexical_map go; // idea of Aleksey Gurtovoy

2.Describe options

 global_options_desc.add_options()
  ( "c", parameters( "", &go.client ), "some comments here"  )
   // Problem #1.
   // The first parameter is a mini-language. Usually C++ tends to avoid
minilanguages.
   // For example: iostreams don't use "w+", "rw", "a", although
iostreams are not always
   // the example of practices to follow.
   // Still, for users minilanguage might be unexpected here
   // Note: need to make sure that parameter can take optional<>

or   ( "c", parameters( "" ), "some comments here"  ) // store it in
the ..._map later

 3. Read - lowest priority first

 // 3.1. Read registry and config file
 // Problem #2 - the names in the registry and config file are not the same
as the names given in options_description
 // actually it seems that the information in options description is
primarily for command line, not for config files.
 // --- custom written ---
mtn::copy( config_file( ".p4config" ), inserter( go ) ); // insert options
in go (variables_map, or lexical_map)
 // --- end custom written ---

 // 3.2. Read command line
 // 3.2.1 Separate global options from command options
 options_and_arguments oa = parse_command_line(argc, argv, desc);
 // Problem #3: Would be nice if options_and_arguments was a  sequence
 command_options_and_arguments = mtn::find_if( options_and_arguments,
&is_argument );
 global_options_and_arguments  = mtn::iterator_range(
options_and_arguments.begin(), command.begin() );

 // 3.2.2. Find out whether I need to read a rest of arguments from standard
input
 // Problem #4: Seems that it is too late to ask boost::program_options to
do that
 // May be the arguments need to be read from stdin and the command line
parsed again?

  // 3.2.3 Store global_options
 store( global_options_and_arguments , go, desc);
 or // Problem #5: need to check how to store into  struct global_options
{}

  // 3.2.4 What command?
 std::string command = *command_options_and_arguments.begin();

 // 3.2.5 Route to module handling command
 modules[ command ].handle_command( command_options_and_arguments );
 or  modules[ command ].handle_command( slice(
command_options_and_arguments, 1 ) ); //without  command itself

// 3.2.5 Handle command in module
handle_command( command_options_and_arguments )
 {
 // define options_descriptions
 store( command_options_and_arguments, desc, command_options );
 }

- END OF IMPLEMENTATION (PSEUDOCODE) ROUND 1 --

Current problems:

1. Early draft - I might have a limited ubdrestanding of some questions (for
example, composing usage strings from

[boost] Re: new version comments

2003-06-02 Thread John Torjo



> Hello John,
>
> I tried assert lib under Borland C++ Builder and Intel C++ and bellow are
> few notes so far.
>
> There seems to be recursive loop bug (item 10).
>
> /Pavel
>
> PS: it is sooo big: 20 headers and > 100kB of source. I would never
imagine
> old
> #define assert(x) if (!(x)) abort()
> can grow so much :-O

;-)

True. But it's got sooo many features ;-)

>
> ---
>
> 1. file smart_assert_persist.hpp:
>
> constructor persistence_context( const char_type * strFile = "", int nLine
=
> 0)
>
> could it be
> persistence_context( const char_type * strFile = 0, int nLine = 0)
> ?

True. Done.
>
> Borland C++ Builder doesn't allow the [= ""] expressions for precompiled
> headers (this is limitation of BC++B). I think
>
> semantic remains the same.
>
> 2. smart_assert_defs.hpp:
>
> typedef enum ignore_type
> declaration needs to end with a name (BC++B).
>
> like:
> typedef enun ignore_type {
>   ...
> } ignore_type;
>
> The same goes for smart_assert_h_ext.hpp and typedef enum
show_details_type.

Done. Thanks.
>
> 3. smart_assert_h_basic.hpp:
> needs
> #include 
> (or #include )
>
> Problem for BC++B: isspace() not recognized.
>
Done.

>
> 4. warnings on BC++B:
>
> I put into boost/smart_assert.hpp:
>
> -
> #if _MSC_VER >= 1020
> #pragma once
> #endif
>
> #ifdef __BORLANDC__
> #pragma warn -8027  // functions not expanded inline
> #pragma warn -8026  // functions with exception spec not expanded inline
> #endif
>
> #include "boost/smart_assert/smart_assert.hpp"
> #include "boost/smart_assert/smart_enforce.hpp"
> #include "boost/smart_assert/smart_verify.hpp"
>
> #include "boost/smart_assert/smart_assert_settings.hpp"
>
> #ifdef __BORLANDC__
> #pragma warn +8027
> #pragma warn -8026
> #endif
>
> #endif

Thanks!
Did it.

At the last #pragma, didn't you mean
// + instead of -
#pragma warn +8026  ?

> 
>
> This got rid of ~20 warnings in Release mode.
>
> 5. smart_assert_alloc.hpp contains tab(s). Tabs are not allowed in Boost
> sources.
>
> line with : void construct(pointer p, const type & v) {
> and line after closing bracket of this function.

Thanks! removed them (it was because I pasted some code from somewhere else)
>
> 6. Maybe there can be some more subdirectories in smart_assert/, like
> handlers/, loggers/, utils/. Right now there are 18
>
> files with the same long prefixes.

Hmm. Yes, I could do this - I'll think about it.

>
> 7. smart_asert_keeper.hpp: please put newline at the end of file. It is
> (IMHO stupid) standard requirement.

Done. I saw it afterwards ;-)
I rechecked all files for this anyhow.

>
> 8. smart_assert_l_ext.hpp, function void erase_logger(int) gives warning
on
> signed/unsigned comparison: can the parameter be
>
> std::size_t?

Done. Thanks.
>
> 9. smart_assert_defs.hpp: the derived exception may conflict with
different
> definitions over different compilers (it happened
>
> often to me).
>
> For Borland C++ Builder I needed to do:
>
> const char *
> #ifdef __BORLANDC__
> // if we use different default calling convention
> __cdecl
> #endif
> what() const throw() {
> return m_val.c_str();
> }
>
>
> and
>
> #ifdef __BORLANDC__
> // if we use different default calling convention
> __cdecl
> #endif
> ~smart_assert_error() throw() {
> }

Done. Thanks!

>
> 10. in smart_assert_keeper.hpp:
>
> the function
> assert_context_func( const assert_context_func & val)
> : m_pimpl( get_clone( val.m_pimpl) ) {
> }
>
> causes infinite loop on BC+B. I think the clone() function recursively
calls
> the constructor. I may dig into it deeper if you
>
> want.
>
> Intel C++ throws access violation on line
>  return pimpl ? pimpl->clone() : 0;

Oops :-(
I redefined the whole assert_context_func - I never liked it the way it used
to be. Please take a look when you have the time - I'll post the new code
soon.

>
>
> 11. smart_assert_ts.hpp can have:
>
> #include 
> #ifndef BOOST_HAS_THREADS
> #  undef BOOST_SMART_ASSERT_THREAD_SAFE
> #endif
>
> in the beginning.
>
> IMO recursive_mutex should be used.

True. I thought about it as well, and that's how it is now.

>
> 12. When I define BOOST_SMART_ASSERT_NO_CUSTOM_ALLOC source cannot be
> compiled (BC++B).
>
> I think it is because of
> typedef std::vector< val_and_str, Private::smart_assert_alloc<
> val_and_str> > vals_array;
>
> in smart_assert_context.hpp.
>
> Error listing:
> --
--
> 
> [...]

O God! What an error :-(
I think I got it. Please recheck if it appears again.

>
>
> 13. Suggestion: maybe function like assert_settings() can be named like:
> assert_settings_singleton()
>
> It is more expressive.

True. But a lot more to type ;-)

>
> 14. Style suggestion:
>
> in templates like
> template< class type>
> type ret_on_fail( const type & val) {
> return val;
> }
>
> the
> templa

[boost] Re: fix of fix

2003-06-02 Thread John Torjo


- Original Message - 
From: "Pavel Vozenilek" <[EMAIL PROTECTED]>
To: "John Torjo" <[EMAIL PROTECTED]>
Sent: Friday, May 30, 2003 10:39 PM
Subject: fix of fix


> Hello John,
> 
> The code I sent before to disable warning isn't the best.
> Here's better version (restores previous settings instead always enabling
> warnings):
> 
> -
> #if _MSC_VER >= 1020
> #pragma once
> #endif
> 
> #ifdef __BORLANDC__
> #pragma warn -8027  // functions not expanded inline
> #pragma warn -8026  // functions with exception spec not expanded inline
> #endif
> 
> #include "boost/smart_assert/smart_assert.hpp"
> #include "boost/smart_assert/smart_enforce.hpp"
> #include "boost/smart_assert/smart_verify.hpp"
> 
> #include "boost/smart_assert/smart_assert_settings.hpp"
> 
> #ifdef __BORLANDC__
> // restore previous settings
> #pragma warn .8027
> #pragma warn .8026
> #endif
> 
> #endif
Thanks. Updated.

> 
> 
> Btw: shouldn't
> #include "boost/..."
> be rather
> #include 

Indeed. Updated.
Best,
John


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

[boost] Re: an XML API in boost

2003-06-02 Thread Anthony Williams

"Reece Dunn" <[EMAIL PROTECTED]> writes:
> Writing an XML parser from scratch for boost should, IMHO, have these
> features:

> [1] It should make use of the Spirit and Regex libraries for XML and XPath
> parsing.

Whilst these libraries might be useful for the parser writer, I don't see any
benefit to requiring their use for a boost XML parser. If a submitted parser
used alternative parsing methods that should be acceptable provided it worked.

> [2]  It should conform to the following W3C standards:
>(a)  XML 1.0 SE while looking at supporting XML 1.1 in the future;

Yes

>(b)  DOM 1.0/2.0/3.0

Hmm. The DOM standards in particular are very Java oriented, and don't
necessarily make for efficient C++ bindings. I can see that the parser needs
to provide the same set of facilities though, even if it is done in a
different way.

>(c) XPath 1.0 with XPath 2.0 support in the future (switch between
>them??)

Yes.

>(d) Unicode 3.x support (I know this is not a W3C standard, but it is
>related)

Yes.

> while these standards would be useful to have support for:
>(e)  XSLT 1.0 with XSLT 2.0 support in the future (select which to use?)

Yes

>(f)  XMLSchema 1.0

Yes

> these standards are optional, but should be implementable using the base
> standards:

>(g)  XSL:FO 1.0
>(h)  MathML 1.0/2.0
>(i)  SVG 1.x/2.x - Scalable Vector Graphics

Agreed to all 3.

IMHO, the base parser should provide an API on which other things can be
built. For example, provided the facilities are present to retrieve the
information needed for XPath processing, the core API doesn't need to have an
XPath processor. Likewise for XSLT.

Actually, the same goes for just about everything, including DTD and Schema
validation --- provided the parser makes all the required information
available then the validation scheme can be provided on top of the core API.

However, I think it is important that the library does include add-on APIs for
as much of the supporting standards as possible, such as DOM-like processing,
XPath node selection, DTD and XMLSchema validation, and XSLT.

> NOTE: The library should be capable of evolving as the web standards evolve.

Of course.

> [3] It should have W3C DOM bindings for the XML document in a way that
> allows support for adding extensions to this, e.g. providing a MathML or SVG
> DOM on top of the XML DOM.

If the DOM API is built on top of the core API, this really comes naturally,
as you can write a new DOM API for specific purposes.

> [4] It should provide XPath bindings to the XML DOM in a clean way; I
> personally like the MS selectSingleNode/selectNodes extension to the XML
> node DOM interface.

There is no point in providing XPath support if it's painful to use.

> [5] It should have a clean access to attributes, without the user needing to
> call get/set methods.

I am not sure what you mean here.

> I am aware that something like this would be a huge undertaking, and that
> there are many tools and libraries that support these or some of these. This
> is just a wishlist for a library that I would be interested in using.

I am developing Axemill (http://www.sf.net/projects/axemill) to fulfil most of
these goals, with the eventual goal of submitting it to boost. If you want to
contribute code and/or ideas, please email me. Currently, it requires gcc 3.2
(though it should build with other relatively conforming compilers) and boost
1.29.0 (I intend to move to 1.30.0 shortly)

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.

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

Re: [boost] Re: Preliminary submission: Finite State Machineframework

Andreas Huber wrote:

Unfortunately, I don't have much experience with anything else than MS
compilers. I will try to port to gcc, but I'll probably need help for
not-so-conforming compilers like Borland.
I have experience with GCC, MS and Borland if you need help porting the 
code.

[snip]
void Pump::Start()
{
   initiate< Idle >(); // * here *
}
Wouldn't this complicate the code that the programmer has to write, whereas 
your version was simpler to implement. (Just my opinion).

I did consider polymorphic events but I wasn't able to make double dispatch
work *automatically* (i.e. without requiring the user to write parts of the
dispatch code themselves).

I personally need polymorphic events only very rarely. Whenever I did, I 
was
always able to change event granularity so that the need would go away. In
your case that would mean to get rid of MouseUpEvent and MouseDownEvent
alltogether and add the information to MouseEvent:

Does the library/code generator you're currently using work with
polymorphic events? Is not having polymorphic events a showstopper for you?
If yes, I would be interested in a as-real-world-as-possible example.
I'm not sure on this, but would Windows-based code that redirects events to 
a Window class be a polymorphic event, e.g.

  class WindowBase
  {
 public:
virtual void Paint( win::api::DC & hDC );
// ...
  };
  class MyGUIWindow: public WindowBase
  {
 public:
void Paint( win::api::DC & hDC ); // custom window graphics
  };
Not sure how you would integrate this with a FSM though!

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

Re: [boost] interest in dominator tree?

2003-06-02 Thread Douglas Gregor

- Original Message -
From: "Jeffrey Hsu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 30, 2003 2:41 AM
Subject: [boost] interest in dominator tree?

> Is there any interest in a generic implementation of the
> Lengauer-Tarjan algorithm to compute the immediate dominator
> tree of a flow graph in almost-linear time?

I'm interested, having recently implemented it myself for the BGL. My only
concern is that the algorithm is very specific to a narrow domain, and might
not belong in Boost. Granted, the thought of a good, _generic_ static
analysis library makes me giggle with glee :)

Doug

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

Re: [boost] [BGL] Patch for nonrecursive DFS to fix stack overflow

2003-06-02 Thread Douglas Gregor

- Original Message -
From: "B B" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 30, 2003 9:52 AM
Subject: [boost] [BGL] Patch for nonrecursive DFS to fix stack overflow


> Here's a patch to depth_first_search.hpp in BGL in version 1.30.0 of boost
> that implements nonrecursive depth first search.  This reduces or
eliminates
> the problem of stack overflow that occurs with DFS in large graphs.  There
> also may be a performance gain in some cases.

This is good. Unless there are any objections, I think we should apply this.

Doug

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

Re: [boost] Patch for the Function library

2003-06-02 Thread Douglas Gregor

Guillaume and Giovanni,
  As Beman mentioned, I've been away for a bit. Let's see if I can answer
some of the lingering what-was-the-maintainer-thinking questions:

Giovanni said:
> Instead, I think this is ill-formed because it's throwing an exception
which
> is not derived from std::bad_alloc().

This is an error. I'll use std::bad_alloc instead.

Giovanni also said:
> What is this code supposed to do? If
> the goal is disabling new() for stateless_integer_add, why simply you
don't
> add a protected operator new as member of the class?

The goal is for the regression test to fail at run time when operator new ()
is being used. The failure needs to be at run time (not compile time, as the
above solution proposes) because the feature we're testing is an
optimization: compilers that can't do it should still compile the code (it
just has slightly different semantics).

Guillaume said:
> The best solution would be to track down compilers that complains if the
> return statement is missing and conditionaly add it for them. But only the
> maintainer can tell us for which compiler the dummy return statement was
> needed. Or maybe we could just remove it and see which compilers suddenly
> complains in the regression tests :-).

Ha! If only the maintainer knew which compiler that was :). If CVS doesn't
tell us, let's just remove the return statement, replace std::runtime_error
with std::bad_alloc, and see who whines about it. I'll commit the patch as
soon as I can, but someone else is welcome to do so if they get there first.

Doug

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

Re: [boost] Re: Single ownership w/weak_ptrs? (was Cyclic smartpointers)

2003-06-02 Thread Larry Evans

Chuck Messenger wrote:
Schoenborn, Oliver wrote:
[snip]
... Strict ownership means that only one object at any
given time can be the owner. This is pretty straightforward and the raw
pointer example shows that there is no such thing as cyclic strict
ownership
that works, at least within the above definition of ownership,

Which is why the strict ownership paradigm doesn't work with cyclic
structures. Inherently, in the general case, cyclic structures
*require* garbage collection (or to be more precise, some dynammic
programming cycle-finding algorithm, whether or not you call it "garbage
collection") to harvest stranded cycles of objects.

Yes, as Peter Dimov suggested, you can sort of "game" the problem by
dividing your structures into Vertex and Edge types, allowing for a
classic strict ownership hierarchy. But that just leaves the garbage
collection problem to the programmer.
OTOH,

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=dilpugnc13c.fsf%40isolde.research.att.com&rnum=1&prev=/groups%3Fdq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Ddilpugnc13c.fsf%2540isolde.research.att.com

seems to support Oliver's viewpoint. I remember reading another post
somewhere where someone required cycles because he was
creating a graph from reading input from a file and couldn't know who
owned who. However, if he's reading from a file, he must
have some map from vertex_name -> vertex_node, and this map
would be the sole owner. All the vertex_nodes would simply be
weak_ptr's to other vertex_nodes.
The above cited post was in a long thread discussing on this topic.
It might be worth reading.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 1.30.0 RPMs

2003-06-02 Thread Rene Rivera

[2003-06-02] Malte Starostik wrote:


>In order to save some time downloading you can as well:
>* get only boost-jam.spec and boost.spec from the URL above
>* get the boost sources from boost.org (tar.bz2 version, not tar.gz)
>* copy tools/build/jam_src/ somewhere else and rename it to
boost-jam-3.1.4/
>* from the boost-jam-3.1.4/'s parent dir, run tar -cf boost-jam-3.1.4.tar 
>boost-jam-3.1.4/ && bzip2 boost-jam-3.1.4.tar and copy the resulting
bzip2ed 
>tarball to the SOURCES subdir of your rpm root directory.
>* build boost-jam with rpm -bb boost-jam.spec and install it

OK, that seems rather arduos when you can just:

cd $BOOST_ROOT/tools/build/jam_src
sh ./build.sh --- dist

Then install the resulting RPM(s).

Any reason why you don't use that instead? Or for that matter use the RPM in
the SourceForge files distribution section?


-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- [EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] 1.30.0 RPMs

2003-06-02 Thread Malte Starostik

Hi,

sorry it took so long, finally I've gotten to building 1.30.0 RPMs. They are 
online at http://malte.homeip.net/boost/ but please do not use that as a 
download site, it's a DSL line with only 16 kbyte/s upstream...

I've had one problem with some of the binary packages on install where rpm 
complained they need libstd++.so, libm.so and libgcc_s.so which I do have 
installed of course. This may be related to the fact that I've updated rpm 
and the build scripts from a newer distro than my base system.
Would be nice if someone could check if that problem occurs as well when 
building on a "sane" system.
Until then, please consider the binary packages partly broken, they're built 
on a with a heavy mix of original Mandrake 9.0 and some updated stuff, so 
there might be library incompatibilities as well...

In order to save some time downloading you can as well:
* get only boost-jam.spec and boost.spec from the URL above
* get the boost sources from boost.org (tar.bz2 version, not tar.gz)
* copy tools/build/jam_src/ somewhere else and rename it to boost-jam-3.1.4/
* from the boost-jam-3.1.4/'s parent dir, run tar -cf boost-jam-3.1.4.tar 
boost-jam-3.1.4/ && bzip2 boost-jam-3.1.4.tar and copy the resulting bzip2ed 
tarball to the SOURCES subdir of your rpm root directory.
* build boost-jam with rpm -bb boost-jam.spec and install it
* build the boost packages with rpm -bb boost.spec and install them

Changes in the boost-jam package:
- version 3.1.4
- switched from .tar.gz to .tar.bz2
- added a workaround so the RPM will also build standalone, i.e. not invoked 
from jam

No real changes in the boost package(s) other than moving to version 1.30.0

Regards,
-Malte

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

[boost] Re: Preliminary submission: Finite State Machine framework

Bohdan wrote:
> Hi Andreas,
>
> It is really nice to hear that FSM lib is ready for submission.
>
> Here are my comments :
>
> 1. Can you port your library to other compilers,
> at least for gcc ? I was trying to port older fersion
> of your lib to Borland, but code is too complicated
> to make it shortly.

Unfortunately, I don't have much experience with anything else than MS
compilers. I will try to port to gcc, but I'll probably need help for
not-so-conforming compilers like Borland.

> 2. I think that nice thing about state machine is
> that you can remove its actual states from interface.
> I mean : "is it conceptually good idea to pass initial
> inner state as a template parameter ?"

Hmmm, I never liked it that much myself but I was forced to design it this
way due to some constraints of an earlier design. Now that you mention it, I
think it should be possible to specify the inner initial state with the
initiate() function, which could be called as follows:

Pump.hpp:

class Pump : public fsm::state_machine< Pump >
{
  public:
void Start();
};

Pump.cpp:

struct Idle : public fsm::simple_state< Idle, Pump >

void Pump::Start()
{
  initiate< Idle >(); // * here *
}

Did you have something like this in mind?

> 3. Why we need state_machine class, wouldn't it
> better to have a single "state" class for
> both state & state_machine.
> IMO state_machine is just state, which can't be
> changed and which doesn't have outer state.
> Am i wrong ?

The state_machine and simple_state templates have quite differing interfaces
and implementation so I'm not sure what that would buy you. Of course, it
would be a simple matter to automatically make a state without an outer
state derive from state_machine behind the scenes but I believe that would
confuse people more than anything else. A state machine handles states and
queues events while a state is not much more than an identifier.

> 4. Is it possible to use inherited events?
> ex:
> class MouseEvent;
> class MouseUpEvent : public MouseEvent;
> class MouseDownEvent : public MouseEvent
>
>  
> bool react( MouseEvent const& event )
> {
> ...
> }
>   
>

No, not exactly as you are suggesting. Although you can derive events from
each other to write common code only once, you must always pass the most
derived type to the fsm::event class template:

template< class MostDerived >
class MouseEvent : public fsm::event< MostDerived >
{
  /* common mouse event code */
};

class MouseUpEvent : public MouseEvent< MouseUpEvent > {};
class MouseDownEvent : public MouseEvent< MouseDownEvent > {};

The best approximation of what you want to do is the following:

struct Idle : public fsm::simple_state< Idle, Whatever, mpl::list<
  fsm::custom_reaction< MouseUpEvent >,
  fsm::custom_reaction< MouseDownEvent > > >
{
  template< class MostDerived >
  fsm::result react( const MouseEvent< MostDerived > & ) { /* ... */ }
};

That is, you can write one react member function for all mouse events but
you have to explicitly mention all most derived classes in the reaction
list.

I did consider polymorphic events but I wasn't able to make double dispatch
work *automatically* (i.e. without requiring the user to write parts of the
dispatch code themselves).

I personally need polymorphic events only very rarely. Whenever I did, I was
always able to change event granularity so that the need would go away. In
your case that would mean to get rid of MouseUpEvent and MouseDownEvent
alltogether and add the information to MouseEvent:

struct MouseEvent : public fsm::event< MouseEvent >
{
  enum ButtonMode { Up, Down };
  ButtonMode mode_;
};

In reactions where you need to discriminate on Up/Down you simply use a
guard.

Does the library/code generator you're currently using work with
polymorphic events? Is not having polymorphic events a showstopper for you?
If yes, I would be interested in a as-real-world-as-possible example.

> 5. Is it possible to inherit state machines:
> some states replaced, some removed ... ?

Unfortunately not. I believe that is only practicable with a code generator.

> 6. Is there any way to get rid of "Acyclic Visitor".
> Some dispatch policies ... ?
> Hope this question isn't too annoying :)

boost::fsm no longer uses acyclic visitor! The current double dispatch
implementation (which was inspired by Aleksey's fsm lib) uses one virtual
call followed by a linear search for a suitable reaction, using one RTTI
comparison per visited reaction. Although you cannot change the double
dispatch implementation itself, you can change one aspect of it, i.e. RTTI.
The BitMachine example shows how to replace native C++ RTTI with integers.

I think only acyclic visitor and the above implementation fit the
scalability requirements as documented in the rationale. While it should be
possible to abstract them in a policy I think that e

Re: [boost] Re: Better Intel-Win32 support

At 03:08 PM 6/1/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> The fresh regression tests are now posted. Here is what changed in the
>> Intel results, presumably as a result of the intel-win32 changes:
>>
>>New fails: config/limits_test
>>   integer/integer_traits_test
>>   utility/counting_iterator_test
>
>All fixed now.
Nice!

We have made a lot of progress recently for three Win32 compilers - Comeau, 
Metrowerks, and Intel. We should get to the point soon we can just email 
the vendors and say, "look, every failure for your compiler represents a 
compiler bug - please fix them!".

--Beman

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

Re: [boost] Re: Better Intel-Win32 support

At 03:09 PM 6/1/2003, David Abrahams wrote:
>"Pavel Vozenilek" <[EMAIL PROTECTED]> writes:
>
>> "Beman Dawes" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>>
>>> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm 
not
>> so
>>> worried about ADL, at least with VC++ <7.1.
>>>
>> You may look on test table
>> http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.
>
>I'm not sure what I should expect to get out of that.  In order to
>make the toolset changes work, when I turn on wchar_t support I also
>define _NATIVE_WCHAR_T_DEFINED on the command-line, so it all works
>out.

That will certainly work, but you shouldn't have to do that since the 
compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier this 
afternoon I am able to compile some non-boost code correctly which had 
previously be failing.

--Beman

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

RE: [boost] Re: [ANN] New Version of the Wave preprocessor libraryreleased

2003-06-02 Thread Hartmut Kaiser

faisal vali wrote:

> Has anyone had problems getting the new wave preprocessor 
> (cpp.cpp) to compile? NMotably any position_policy error 
> messages (not defined in spirit and
> such...)
> Also i've been getting some linker errors - 
> I'm using gcc 3.2.1 (is that the problem?)
> any clues will be appreciated.
> regards,

Sorry or the late reply, I was out of town for some days ...

Yes, your problem is known, it was reported only recently. The problem
is, that the current Wave sources does not compile with the Spirit
distribution, contained in the Boost V1.30.0 release. This has to be
fixed, but for now I suggest to get the latest sources from the Spirit
CVS. There should be a new Spirit release really son now, so your other
option is to wait a couple of days until Spirit 1.6.1 is out.

Regards Hartmut

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

[boost] Re: Better Intel-Win32 support

"Pavel Vozenilek" <[EMAIL PROTECTED]> writes:

> "Beman Dawes" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not
> so
>> worried about ADL, at least with VC++ <7.1.
>>
> You may look on test table
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.

I'm not sure what I should expect to get out of that.  In order to
make the toolset changes work, when I turn on wchar_t support I also
define _NATIVE_WCHAR_T_DEFINED on the command-line, so it all works
out.

> (Warning : when playing with options I managed to break something in
> compiler configuration and as result compiler decided to define macro
> indicating wchar_t support _always_.)
>
> /Pavel
>
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

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

Re: [boost] Re: Better Intel-Win32 support

At 02:50 PM 6/1/2003, Pavel Vozenilek wrote:

>
>"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>>
>> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm 
not
>so
>> worried about ADL, at least with VC++ <7.1.
>>
>You may look on test table
>http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.
>
>(Warning : when playing with options I managed to break something in
>compiler configuration and as result compiler decided to define macro
>indicating wchar_t support _always_.)

I've made the fix as you indicated. If that isn't right, let me know.

Thanks,

--Beman 

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

[boost] Re: Better Intel-Win32 support

Beman Dawes <[EMAIL PROTECTED]> writes:

> The fresh regression tests are now posted. Here is what changed in the
> Intel results, presumably as a result of the intel-win32 changes:
>
>New fails: config/limits_test
>   integer/integer_traits_test
>   utility/counting_iterator_test

All fixed now.

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

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

[boost] Re: Better Intel-Win32 support

2003-06-02 Thread Pavel Vozenilek


"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not
so
> worried about ADL, at least with VC++ <7.1.
>
You may look on test table
http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864.

(Warning : when playing with options I managed to break something in
compiler configuration and as result compiler decided to define macro
indicating wchar_t support _always_.)

/Pavel



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

Re: [boost] Better Intel-Win32 support

At 12:09 PM 6/1/2003, David Abrahams wrote:

>Beman Dawes <[EMAIL PROTECTED]> writes:
>> Looks much improved, thanks!
>>
>> Two of the config_info macros look a bit questionable:
>
>I don't know what you mean; I didn't touch the Boost config.  All I
>did was to edit intel-win32-tools.jam.
Understood. But now that the toolset is working much better I'd also like 
to see if we can fix any other problems, such as config issues.

>  Did you follow the link above?

Yes, looks nice. I changed my environment variables as indicated, and they 
worked fine.

>
>>  BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP   [no value]
>>  BOOST_NO_INTRINSIC_WCHAR_T   [no value]
>>
>> Perhaps BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is needed to be able to use 
the
>
>> Microsoft library?
>>
>> BOOST_NO_INTRINSIC_WCHAR_T seems completely wrong. That isn't even set 
for
>
>> VC++7.0. Or am I missing something? (The command line is below.)
>
>If config_info is showing wrong answers, I can't help it, though I am
>not at all sure ADL is enabled for this compiler.  I didn't change
>much about the command-line options that get used with Intel7 anyway.
>If you want to try to add -Qoption,c,--no-microsoft-bugs when the
>compiler is version 7, you could try to do that, but you'd better
>test it atop each of the vc6, vc7, and vc7.1 standard libs to make
>sure it's actually compatible.

I'll try to trace where BOOST_NO_INTRINSIC_WCHAR_T is being set. I'm not so 
worried about ADL, at least with VC++ <7.1.

The fresh regression tests are now posted. Here is what changed in the 
Intel results, presumably as a result of the intel-win32 changes:

  New fails: config/limits_test
 integer/integer_traits_test
 utility/counting_iterator_test
  New passes: lambda/exception_test
  numerics/ublas/test5
--Beman

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

Re: [boost] Better Intel-Win32 support

Beman Dawes <[EMAIL PROTECTED]> writes:

> At 11:12 AM 6/1/2003, David Abrahams wrote:
>  >
>  >I just checked in some improvements to intel-win32 support for
>  >Boost.Build version 1.  This includes a hack which works around our
>  >inability to detect wchar_t support for intel6.  It also includes
>  >automatic version detection and resulting customization to the
>  >command-line options.  Please see http://tinyurl.com/d6kw to review
>  >the new configuration.
>
> Looks much improved, thanks!
>
> Two of the config_info macros look a bit questionable:

I don't know what you mean; I didn't touch the Boost config.  All I
did was to edit intel-win32-tools.jam.  Did you follow the link above?

>  BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP   [no value]
>  BOOST_NO_INTRINSIC_WCHAR_T   [no value]
>
> Perhaps BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is needed to be able to use the 
> Microsoft library?
>
> BOOST_NO_INTRINSIC_WCHAR_T seems completely wrong. That isn't even set for 
> VC++7.0. Or am I missing something? (The command line is below.)

If config_info is showing wrong answers, I can't help it, though I am
not at all sure ADL is enabled for this compiler.  I didn't change
much about the command-line options that get used with Intel7 anyway.
If you want to try to add -Qoption,c,--no-microsoft-bugs when the
compiler is version 7, you could try to do that, but you'd better
test it atop each of the vc6, vc7, and vc7.1 standard libs to make
sure it's actually compatible.

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

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

[boost] Re: Preliminary submission: Finite State Machine framework

Aleksey,

[snip]
> So, while here at work we have developed an in-house technology
> that achieves that goal for small-to-medium FSMs (the first prototype
> of which is outlined in the MPL paper), I am really looking forward to
> studying experts' work on the subject.

Thanks, but I'm by no means an expert! All experience I have is some 1.5
years of heavy exposure. I was hoping that an expert would maybe tune into
the discussion here at boost.
BTW, an adapted version of your double-dispatch implementation made it into
my library.

> Well, meanwhile, besides the above, my first comment is going to be
> really minor - I browsed over the tutorial (which looks great!), and
> although I am sure you know it, I thought it would be worth to point
> out that the 'public' specifier is redundant when the derived class
> is declared as 'struct'; if you omit those, the examples' syntax would
> become even more DSL-like (== better :).

Good point (I didn't know as I'm not using structs all that often), I will
change code and docs accordingly. However, I won't release for about two
weeks, as reviewers might get confused if changes happen more often.

Thanks,

Andreas


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

Re: [boost] Better Intel-Win32 support

At 11:12 AM 6/1/2003, David Abrahams wrote:
>
>I just checked in some improvements to intel-win32 support for
>Boost.Build version 1.  This includes a hack which works around our
>inability to detect wchar_t support for intel6.  It also includes
>automatic version detection and resulting customization to the
>command-line options.  Please see http://tinyurl.com/d6kw to review
>the new configuration.
Looks much improved, thanks!

Two of the config_info macros look a bit questionable:

BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP   [no value]
BOOST_NO_INTRINSIC_WCHAR_T   [no value]
Perhaps BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is needed to be able to use the 
Microsoft library?

BOOST_NO_INTRINSIC_WCHAR_T seems completely wrong. That isn't even set for 
VC++7.0. Or am I missing something? (The command line is below.)

Regardless, I'm now rerunning the full regression tests for intel-win32, 
and will let you know if it turns up anything interesting.

Thanks,

--Beman

"D:\Program Files\Intel\Compiler70\IA32\bin\icl"  /Zm800 -nologo -GX 
-c   /Z7 /Od /Ob0 /GX /GR /MDd /Op  /Zc:wchar_t,forScope /Qwn5 /Qwd985 
/Qansi_alias 
/Qvc7  -I"d:\boost-regr\status"  -I"C:\boost\site" 
-Fo"d:\boost-regr\status\bin\config_info.test\intel-win32\debug\runtime-link-dynamic\config_info.obj" 
-Tp"C:\boost\site\libs/config/test\config_info.cpp"

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

[boost] Better Intel-Win32 support