Number of parameters for flag is controlled by the last parameter to
addSupportedFlag(), which is of type QStringList. If this string list is empty,
the flag accepts no parameters. If it is non-empty, then the flag accepts the
same number of parameters as there are items in the string list. The string
list merely specifies the names to give the parameters in the usage/help
message.
Type checking could be added easily by the client where it is needed. If your
subclass wants to operate on specific types, then the neat way to do it would
be to add a member function to your subclass to encapsulate that conversion.
Your validate() function would normally handle checking whether parameters that
need to be convertible to a specific type can indeed be converted. For example,
if there was a flag that was expected to have one parameter that was
convertible to int, it could fairly trivially be implemented something like
this:
int getSomeFlagParam1() const
{
// Would normally check that the parameter is convertible to int
// from within validate()
return QVariant(flagParameter("someFlag", 0)).toInt();
}
On 22/10/2011, at 5:18 PM, Иван Комиссаров wrote:
Oops, sorry, it can check flags:) didn't saw addSupportedFlag method:(
So only issue is type-checking (and number of parameters for flag)
22.10.2011, в 10:15, Иван Комиссаров написал(а):
Hi, your implementation can't automatically check if flags exists (you should
ask it manually instead, which is painful - adding new flags will require tons
of if-spagetti) and automatically print usage/help if something is wrong, also
it doesn't have type-checking of input parameters. Too simple, as for me.
22.10.2011, в 4:29, <craig.sc...@csiro.au<mailto:craig.sc...@csiro.au>>
<craig.sc...@csiro.au<mailto:craig.sc...@csiro.au>> написал(а):
On 22/10/2011, at 5:18 AM, Thiago Macieira wrote:
On Friday, 21 de October de 2011 16:29:36 Stefan Majewsky wrote:
Moin moin,
it would be nice to have a command line parser in QtCore, i.e. some
class that parses stuff like
./program -vh --long-option --value=5 foo.dat
given some format definition. KCmdLineArgs and KCmdLineOptions from
kdecore do exactly that for KDE programs. I don't have time right now,
but perhaps someone wants to pick up this task?
Hello Stefan
Speaking as QtCore's maintainer, I'll reserve the decision until I see your
proposal.
A while back, we also found ourselves in need of decent command line parsing.
It kinda surprised me that Qt didn't offer anything already in this area, since
it seemed like the sort of thing that Qt would normally provide. So we
considered our options. Our apps are not KDE apps, so we were not able to look
there for a solution. We also do not use boost (let's not debate that, it's not
the point of this post), so we were not able to use their solution either. In
the end, we decided we needed to write our own, which we did. At the time, I
had the thought that if we do it right, maybe one day we could consider
contributing it back to become part of Qt. Funny how things come around......
Let me state a couple of things before going further. The code in question is
100% our own, so no issues with copyright and contributors, etc. I'd just have
to get formal approval from our legal people to release it (that would take
time, but since this code isn't particularly novel, I think I can get that
approval). Our solution currently supports the main needs for a command line
parser, but it won't have every bell and whistle people might want. That said,
I don't think it would be particularly difficult to add support for the main
omissions.
With that out of the way, I've put the class definition up on pastebin for
comment. I've withheld the implementation until I've had a chance to clear it
with our legal people. In the meantime, I think the interface of the class is
probably enough to get some feedback on whether people think this has the
potential to be a viable candidate for a command line parser for Qt:
http://pastebin.com/45PiHzLA
Note that the code currently does not adhere to the Qt coding guidelines (it
follows ours instead), but if we do end up contributing it to Qt, then it
should not be too difficult to bring it into line.
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com<mailto:Qt5-feedback@qt.nokia.com>
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com<mailto:Qt5-feedback@qt.nokia.com>
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
