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.tf@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>& 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) ---------------------------------------------------------------------------- -------------------- 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.tf@acm.org Thanks to all Renato
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@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
On Thu, Jan 26, 2012 at 6:41 PM, Christof Donat <cd@okunah.de> wrote:
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 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...
Hi,
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 tutorial explains this. Also, see main_tutorial_3.cpp.
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 > instead of the C like 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 >, you could use argv[0] and argv[argc], or any other 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 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
On Thu, Jan 26, 2012 at 8:57 AM, Renato Tegon Forti <re.tf@acm.org> wrote:
* Is there any interest in this library? * If Yes! What are the refinements? (see todo, for some)
1. 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.
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)
So selling it as "ready to play" UNIX/Linux daemon is a bit - erm - exaggerating.
Sorry about this, I will change this description! I agree with you! Sorry! b)
Why is the application not a functor or even a function? .
Again I agree with you! This is a better way!, for sample I can handle exception in my main too! Thanks about this suggestion!
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.
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)
The biggest concern for me is that you're using narrow strings
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: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] Em nome de Joshua Boyce Enviada em: quinta-feira, 26 de janeiro de 2012 06:05 Para: boost@lists.boost.org Assunto: Re: [boost] Boost.Application On Thu, Jan 26, 2012 at 8:57 AM, Renato Tegon Forti <re.tf@acm.org> wrote:
* Is there any interest in this library? * If Yes! What are the refinements? (see todo, for some)
1. 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
participants (3)
-
Christof Donat -
Joshua Boyce -
Renato Tegon Forti