Omgili, forum search, forums search, search forums, discussion search,discussions search, search discussions, board search, boards search, search boards
  Advanced Search

[boost] Boost.Application

On Wed, 25 Jan 2012 19:57:32 -0200, "Renato Tegon Forti" <...@acm.org

Hi All,

I have the first prototype of the "Boost.Application" ready!

I would like to receive comments so I can refine the library. Please send
your feedback to re.t...@acm.org

0) Introduction

A Boost.Application allows a developer run your application as a Windows
service, as a Unix/Linux daemon, or as a usual interactive application
(terminal) without the need to add extra code, the library abstract OS
specific API and provide a ease common interface.

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.

CTRL-C signals and SCM (Service Control Manager) controls handlers are
available for terminating, pause/resume(windows) the application
constructively and many other until methods are available in application
class like a single instance running limitation!

1) Download:

https://sourceforge.net/projects/boostapp/

2) Installation:

The library is one: Automatic linking

You should unpack the files and copy:

Boost.Application_pre_alpha_1\boost\application
To:
boost_1_48_0\boost
and,
Boost.Application_pre_alpha_1\libs\application
To:
boost_1_48_0\libs

3) Build

Then you must build, for example (in windows):

bjam toolset=msvc-9.0 variant=debug threading=multi link=shared
define=_BIND_TO_CURRENT_VCLIBS_VERSION

4) Documentation

The project has an incomplete documentation:

Boost.Application_pre_alpha_1\libs\application\doc\html\index.html

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 {
// 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)

----------------------------------------------------------------------------
--------------------

The folder:

Boost.Application_pre_alpha_1\libs\application\example\tutorial

Has all tutorial files!

I tested the lib on Windows VC9 (Windows Service) and Ubuntu 11 GCC 4
(Daemon)!

6) Questions:

* Is there any interest in this library?
* If Yes! What are the refinements? (see todo, for some)

Please send your feedback to re.t...@acm.org

Thanks to all
Renato

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



On Thu, 26 Jan 2012 08:41:36 +0100, Christof Donat <...@okunah.de

Hi,

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

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.

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 boost::application::application< myapp,
boost::application::default_application_type {
// 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 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 http://www.okunah.de
86153 Augsburg c...@okunah.de

Registergericht Augsburg
Geschäftsführer Augsburg HRB 21896
Christof Donat UStID: DE 248 815 055

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

On Thu, 26 Jan 2012 19:08:50 +1100, Joshua Boyce <...@raptorfactor.com

On Thu, Jan 26, 2012 at 6:41 PM, Christof Donat <...@okunah.deThe tutorial explains this. Also, see main_tutorial_3.cpp.

While we're on the topic of parsing command line arguments though, that is
another spot I'd definitely like support for wide strings (see wmain,
wWinMain, GetCommandLineW, etc). Well, pretty much everywhere tbh...

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

On Thu, 26 Jan 2012 10:56:21 +0100, Christof Donat <...@okunah.de

Hi,

I see, thanks. I don't like it, though I don't have an alternative
solution at hand. Somehow this feels very clumsy with that init()
method. As example of a pure OO approach you could have a look at Qts
QApplication. That one gets argc and argv as constructor parameters. Yet
I do like the idea of using a vector< string argc and argv construct.

Another approach would be to better integrate the Application and
program_options. E.g. the Application could be initialized with an
options object and a container object to hold the parsed options. Then
the main() method (or, what I'd prefer the call operator) would simply
get the already parsed parameters.

Of course there is also the option to extend program_options so that it
can parse not only from argc and argv, but from a range of string like
objects. Then you could use begin() and end() to create a range from the
vector< string kind of range. That might also be usefull for situations where
application is not used.

Personally I'd prefer the last option, because it opens up new
possibilities for other situations as well and keeps application
flexible as well. Integrating program_options in application would take
away the liberty from the user to not use program_options for whatever
reasons. The idea with init() is clumsy and passing argc and argv to the
constructor is just like passing them to the main method itsself.

Christof

--
okunah gmbh Software nach Maß

Werner-Haas-Str. 8 http://www.okunah.de
86153 Augsburg c...@okunah.de

Registergericht Augsburg
Geschäftsführer Augsburg HRB 21896
Christof Donat UStID: DE 248 815 055

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

On Thu, 26 Jan 2012 19:05:10 +1100, Joshua Boyce <...@raptorfactor.com

On Thu, Jan 26, 2012 at 8:57 AM, Renato Tegon Forti <...@acm.org1. Yes, there is definitely interest from me at least.

2. The biggest concern for me is that you're using narrow strings
everywhere under Windows, including calling the narrow APIs (e.g.
GetModuleFileNameA). Please consider using wide strings on Windows,
otherwise those of us who require Unicode support in our applications are
unable to use your library. Use of the narrow APIs under Windows is
deprecated and should be avoided anyway... Perhaps you could look at how
Boost.Filesystem handles the Unicode 'fiasco' (wstring vs string for
platform independent libraries)? Just please don't do what
Boost.ProgramOptions does (or at least, did last time I looked), which is
effectively just static_cast'ing wchar_t to char internally when you pass
it wide strings.

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

On Thu, 26 Jan 2012 10:26:05 -0200, "Renato Tegon Forti" <...@acm.org

Hi all,

I want to emphasize:

1) This is a prototype, a starting point to find out if this is an
interesting lib to boost!
2) And if 1 is true! I will compile all comments and make modifications to
meet "boost"!

My doubt is if this lib don't violate: "The library must be generally useful
and not restricted to a narrow problem domain."
About comments of friends!

First, thank you for the comments! They always show a new way of doing
things, which I had not thought of! This is the main reason I'm doing
(trying to) this lib, to have the opportunity to learn (and contribute) with
you!

I will try to enumerate the comments, and then build a path to follow for
next version (if [1] is satisfied. Do you think I need more votes to
continue the effort?)

a)

exaggerating.

Sorry about this, I will change this description! I agree with you! Sorry!

b)

Again I agree with you! This is a better way!, for sample I can handle
exception in my main too! Thanks about this suggestion!

Somehow this feels very clumsy with that init() method. As example of a pure
OO approach you could have a look at Qts
QApplication.

I will look QApplication! If you have time! You could describe what you
think would be the right path follows in more detail, I appreciate it!

c)

I will provide wide strings. I don't know how yet. I will check
Boost.Filesystem! Besides, there is other example to follow?

For sample, I need use W version (GetModuleFileNameW) on all? And use a
function like this to convert:

inline void convert(const char* from, std::wstring & to, const codecvt_type&
cvt)

D)

Other question, to handle exceptions! Any Idea?

e)

"Install and uninstall windows service" functionality, be a part of the
application instead of a separate one and using a callback.

f)

* In the unknown mode, the program can run in either mode provided someone
puts something in the command line.

Could that rather be a callback maybe post initialize such that we tell your
application which one we want.

This way the developer controls his command line.

After all, it might not come from the command line but instead from a
configuration file.

--------------------------------------------------------------------------

What else?

Thanks for help!!!

-----Mensagem original-----
De: boos...@lists.boost.org [mai...@lists.boost.org] Em
nome de Joshua Boyce
Enviada em: quinta-feira, 26 de janeiro de 2012 06:05
Para: boos...@lists.boost.org
Assunto: Re: [boost] Boost.Application

On Thu, Jan 26, 2012 at 8:57 AM, Renato Tegon Forti <...@acm.org1. Yes, there is definitely interest from me at least.

2. The biggest concern for me is that you're using narrow strings everywhere
under Windows, including calling the narrow APIs (e.g.
GetModuleFileNameA). Please consider using wide strings on Windows,
otherwise those of us who require Unicode support in our applications are
unable to use your library. Use of the narrow APIs under Windows is
deprecated and should be avoided anyway... Perhaps you could look at how
Boost.Filesystem handles the Unicode 'fiasco' (wstring vs string for
platform independent libraries)? Just please don't do what
Boost.ProgramOptions does (or at least, did last time I looked), which is
effectively just static_cast'ing wchar_t to char internally when you pass it
wide strings.

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

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

Discussion Title: [boost] Boost.Application
Title Keywords: [boost]  Boost.Application