Boost logo

Boost :

Subject: Re: [boost] Boost.Application
From: Christof Donat (cd_at_[hidden])
Date: 2012-01-26 02:41:36


Hi,

First of all, I appreciate yout efforts. This mail mostly includes criticism
for brevity, not because I have only criticism for it.

> In case of server application, developer need only compile your code on a
> Windows to have a ready to play Windows Service or in a UNIX/Linux to have
> Daemon.

I guess, it does not generate all the start and stop scripts for SysV init,
BSD init and newer replacements. So selling it as "ready to play" UNIX/Linux
daemon is a bit - erm - exaggerating.

> 5) Use
>
> however, the tutorial explains how to use the lib, and that generally goes
> like this:
>
> ----------------------------------------------------------------------------
> --------------------
> #include <boost/application/engine.hpp>
>
> class myapp : public boost::application::application
> {
> protected:
> int main(const std::vector<std::string>& args)
> {
> // your application logic here!
> while(1)
> {
> std::cout << "Hello Boost.Application!" << std::endl;
> // ...
> if(state() == boost::application::application_stoped)
> {
> break;
> }
> }
> return 0;
> }
> };
>
> BOOST_APP(myapp, "MainTutorial1", "Boost.Application Main Tutorial 1!",
> boost::application::default_application_type, 1, 0, 1)
>
> ----------------------------------------------------------------------------
> --------------------

Why is the application not a functor or even a function? I also don't like
that macro at the end. I'd prefer to write a main function explicitly. So for
me it should more look something like this:

----------------------------------------------------------------------------
#include <boost/application.hpp>

class myapp
{
  public:
    int operator()( const std::vector< std::string >& args,
      boost::application::application< myapp,
        boost::application::default_application_type >& app )
    {
        // your application logic here!
        do
        {
            std::cout << "Hello Boost.Application!" << std::endl;
            // ...
        } while( app.state() != boost::application::application_stoped );
        return 0;
    }
};

// this is a minimal main(). It could also include more sophisticatet logic,
// like e.g. depending on the command line start different applications or
// application types.

int main( int argc, char** argv )
{
    myapp application_functor;
    // instantiate application object
    boost::application::application< myapp,
        boost::application::default_application_type >
      app( application_functor,
          // whatever these parameters are for. Looks like platform specific
          // requirements for windows.
           "MainTutorial1", "Boost.Application Main Tutorial 1!");

    // run the application and return its return value
    return app( argc, argv );
}
----------------------------------------------------------------------------

When writing an application, how do I use boost::program_options to parse a
std::vector< std::string >? At least I have not found any overloaded version
of parse_command_line(). Maybe I have just not seen it.

The advantages would be:
1. The application can even simply be a function.
2. The main() can include more sophisticated logic as well
3. myapp::main() needs to be virtual, my functor does not. Well it should only
be called once, so that shouldn't be a big performance issue, but when the
functor comes from a template instantiation like e.g. boost::bind() virtual is
not the very best idea.
4. At least for me that feels more boost like. Yours feels - sorry to say so -
a bit Java like. It just does not integrate well.

Christof

-- 
okunah gmbh                                  Software nach Maß
Werner-Haas-Str. 8                               www.okunah.de
86153 Augsburg                                    cd_at_[hidden]
                                      Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk