Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-23 18:17:23

--- In boost_at_y..., "Schoenborn, Oliver" <oliver.schoenborn_at_n...>
> > Schoenborn, Oliver wrote:
> > > > I'm not clear on the need to distinguish between long and
> > > > option names. What I would have is a 'minimum abbreviation
> > > > setting, whereby you must have at least x unambiguous letters
of the
> > > > option name for it to be recognised.
> > >
> > > Sorry if this has already been explicitly ruled out, but is
there a
> reason
> > > for not distinguishing between long and short arguments by
using - for
> > > short and -- for long?
> >
> > I find it the best syntax. In fact, this is what you get with the
> predefined
> > "unix" style. However, people was asking for long options names
with a
> single
> > dash/slash.
> >
> > - Volodya
> Yes, but just because users ask for it doesn't mean it is a good
feature to
> have. If Stroustrup were to have accepted everything that users
wanted into
> the C++ language, it would be a mess. Why not keep things simple,
> without sacrificing true versatility? I suspect that only a very
> minority of users would need the long options with one '-' so bad
that they
> would refuse to use the boost command line library.

I don't agree. Using two sets of switch charaters with two distinct
sets of command line options will just confuse most users, and serves
no purpose when "long options" require only as many characters as
required to distinguish it from other "long options". The use of
multiple switch characters is actually what I find most annoying of
Unix style command line parsing. If a command line parser must pick
a single way to parse (I don't agree that it should) then I'd
strongly argue for '/' or '-' denoting the beginning of an option,
with the option matching any subset of charactes in any of the valid
options that reduces to a single choice, and other options/arguments
would then be required to be seperated by white space.

I bet many people would agree with me... especially those from non-
Unix backgrounds. I'd be surprised if the numbers that agreed
represent a "small minority" of users (especially if you include
actual users and not just programmers).

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at