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