Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Subject: GetOpt++
Date: Sun, 14 Apr 2002 00:34:02 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5E1F@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Cygwin-Apps" <cygwin-apps AT sources DOT redhat DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3DEYB509076

I've created a little library based around the design I created for
command line options in setup.exe. I did the design after I had a good
look round on the web and couldn't see any good object orientated
command line approach. It's configured to build with the setup String++
class, or to use the libstdc++ string class. I'm seriously considering
removing the setup.exe code and dropping the library in instead
(integrated into the single-build process of course).

The library isn't feature complete, but I'll be using it for all my c++
code from here on in, so unlike the GUI resource editor/windres, I can
guarantee that this will see a resonable commit rate :}. It's GPL
licenced if anyone is interested, and builds both shared and static
versions OOTB.

Anyway, I've called it GetOpt++, and am looking for a home site (CVS + a
web page or two. If it gets lots of mail, then a mailing list I guess).
So Chris, is this a cyg-apps or sources.redhat.com repository candidate,
or do I toddle off to sourceforge or an equivalent site?

For the curious, the key design goals of the library are:
1) Object based, not procedural. Some immediate corollaries are that
there is minimal footprint in main.cc, and no header or source changes
outside the user of an option when the option is altered/a new option
added. 
2) Multiple option sets can co-exist safely. The default option set is a
singleton, but additional static sets can be created and used.
3) Easy to use. I've removed the need to subclass Option from the
design, adding a new option is now simply a case of adding a static
variable for the option, in the scope that the option needs to be
visible - be that class scope or translation unit scope. There are (will
be when feature complete) multiple concrete Option classes provided
(currently BoolOption is the only one implemented).

On a further note, the difference between libGetOpt++ and the GNU libg++
GetOpt class is this: the GNU libg++ GetOpt class is procedural in
nature (99% of it's use is the same as for normal getopt) whereas
GetOpt++ uses getopt.h to do the grunt work and exposes an object based
interface. You could almost call GetOpt++  a C++ binding to getopt, but
I feel the design approach is different enough that it's more than a
simple language binding.

Rob

p.s. here is a sample program using it, as proof that it's not onerous
to use :]

#include <getopt++/GetOption.h>
#include <getopt++/BoolOption.h>

static BoolOption testoption (false, 't', "testoption", 
"Tests the use of boolean options");

int
main (int argc, char **argv)
{
  if (!GetOption::GetInstance().Process (argc, argv))
    {
      cout << "Failed to process options" << endl;
      return 1;
    }
  if (testoption)
    {
      cout << "Option used" << endl;
      return 1;
    }
  else
    {
      cout << "Option not used" << endl;
      return 0;
    }
}