After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 393571 - option parser ignores default values
option parser ignores default values
Status: RESOLVED DUPLICATE of bug 336598
Product: glibmm
Classification: Bindings
Component: general
2.13.x
Other All
: Normal normal
: ---
Assigned To: Daniel Elstner
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2007-01-06 16:26 UTC by Daniel Elstner
Modified: 2007-02-10 19:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Elstner 2007-01-06 16:26:21 UTC
The contents of the option value passed to Glib::OptionGroup::add_entry() by reference are always cleared.  E.g. if you do this:

bool do_foo = true;
Glib::OptionEntry entry;
Glib::OptionGroup group;
entry.set_long_description("no-foo");
entry.set_flags(Glib::OptionEntry::FLAG_REVERSE);
group.add_entry(entry, do_foo);
...

After parsing the options, do_foo will always be false, irrespective of whether you pass the "--no-foo" option or not.  Looking at the code, it appears that OptionGroup::CppOptionEntry::allocate_c_arg() just always initializes the allocated value using the default constructor, instead of copying the value from the location passed to OptionGroup::add_entry().
Comment 1 Murray Cumming 2007-02-10 14:14:38 UTC
Do you mean that if we do, for instance:

  Glib::ustring arg_foo = "some default value";
  Glib::OptionEntry entry1;
  entry1.set_long_name("foo");
  entry1.set_short_name('f');
  entry1.set_description("The Foo");
  add_entry(entry1, arg_foo);

  Then arg_foo will be "" if the user does not specify it? So the caller has to check whether it's empty and then explicitly use a default value.


Yes, I had not considered that would be wanted. I guess I just like to initialize output variables in case the caller doesn't do it. That might be a disadvantage here.
Comment 2 Armin Burgmeier 2007-02-10 17:22:13 UTC
I already stumbled about this some time ago, however it seems that the patch got lost somehow. Refer to http://bugzilla.gnome.org/show_bug.cgi?id=336598.
Comment 3 Daniel Elstner 2007-02-10 19:15:42 UTC

*** This bug has been marked as a duplicate of 336598 ***