Subject: [boost] RES: Boost.Application
From: Renato Tegon Forti (re.tf_at_[hidden])
Date: 2012-01-26 07:26:05
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
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
I will try to enumerate the comments, and then build a path to follow for
next version (if  is satisfied. Do you think I need more votes to
continue the effort?)
>>So selling it as "ready to play" UNIX/Linux daemon is a bit - erm -
Sorry about this, I will change this description! I agree with you! Sorry!
>> 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
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!
>> 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&
Other question, to handle exceptions! Any Idea?
"Install and uninstall windows service" functionality, be a part of the
application instead of a separate one and using a callback.
* 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
Thanks for help!!!
De: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] Em
nome de Joshua Boyce
Enviada em: quinta-feira, 26 de janeiro de 2012 06:05
Assunto: Re: [boost] Boost.Application
On Thu, Jan 26, 2012 at 8:57 AM, Renato Tegon Forti <re.tf_at_[hidden]> 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
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk