Hello Julian, Thank you for your consideration, are very important! About the interface, in the first version (release 1) , the interface of the lib are exactly what you proposed. But this bring so problems to extend lib in the future, then I resolved to use a more complex interface, but that are more flexible, using Boost.Parameter (iten 2 of change list)! However, is easy to provide both interfaces, and I will think in a way to create a wrapper class, and provide the both interfaces. I will wait for more consideration on this subject to have a more clear perception, about what is desirable by boosters! About Documentation! I agree with you that documentation is very bad writing! I have "dyslexia", and even in my native language (which is Portuguese), I don't write well! I want to take and ask for help, if any native speaker of English can help me with the documentation! Contact: re.tf@acm.org Again, thanks for the comments! They will be considered for the next version! Renato -----Mensagem original----- De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de Julian Gonggrijp Enviada em: sexta-feira, 20 de setembro de 2013 08:26 Para: boost@lists.boost.org Assunto: Re: [boost] Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a Renato Forti wrote:
Here are the online docs to the library:
http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.h tml
I had a quick look at the documentation and I certainly think your library could be useful. I do have one concern about the API, and a few remarks about the documentation. My concern about the API: In order to create an interactive application, the body of main would be return application< my_application<myapp> >( args(argc, argv) )(); while for a server it would be return application< application_type<server_application>, my_application<myapp> >( args(argc, argv) )(); . I find this counterintuitive for three reasons. The first is that my_application appears to be a template provided by the application library, so it isn't "mine" at all. I only created myapp so that is the only entity that should be allowed to have "my" in the name. Secondly, I need two nested templates in order to launch my application class. There is no immediately obvious reason why it couldn't be just a single template. The third reason is that I need to specify the application type for a server but not for an interactive application, and that this optional template parameter comes before the required parameter, i.e. the template that actually wraps my application class. Concluding, I would find the following interface much more natural: return interactive_app<myapp>(args(argc, argv))(); return server_app<myapp>(args(argc, argv))(); for interactive applications and server applications, respectively. Perhaps this isn't possible, but then at least the very start of the documentation should give the user an understandable reason why the interface needs to look so complicated. In any case, please let the optional template parameters come after the required parameters. My remarks about the documentation: The English leaves a lot to be improved upon. There are eye-catching typos, such as "Handlres" in one of the section titles and "avector" in the two minute introduction, as well as many subtle ellipses and other syntactical errors that make the text a bit unnatural and harder to read. This may not seem important, because it doesn't make your library any less valid and it probably wouldn't affect the outcome of a future review (much), but it will be easier to get a review at all if you improve the language. Potential reviewers and review managers may get the impression they can't take your library seriously after a first glance at the documentation, so I think it would be advisable to give this first priority. I would recommend getting help from a (near-)native speaker to clear up the syntax. There are lots of exclamation marks in the text. This gives a "screamy" and not-so-serious appearance. I compared the Windows and Unix tutorials and the example code is completely identical, except for a single line in the blocking stop at the end. That difference isn't even strictly necessary as it is the omission of a line that would be ignored in Unixy systems anyway. I think you should merge the tutorials, both to show that your library meets the goal to write portable applications and to illustrate how a decision in the code affects both platforms, regardless of what platform the user is most interested in. Hope this helps! -Julian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost