Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gaps between specification and implementation in typed_value::composing() #124

Open
mdj982 opened this issue Jul 22, 2023 · 0 comments
Open

Comments

@mdj982
Copy link

mdj982 commented Jul 22, 2023

Description and Reproduction

Consider Example 63.2 (Execution on Wandbox)

test --phone 123 --phone 456

In this case, both phone numbers, 123 and 456, are parsed. The call to composing() makes it possible to use a command-line option multiple times – the values are composed.

From this description, it would seem that, conversely, without the call to composing(), only 123 would be assigned to the --phone option but 456 would be ignored. (I assume this is the specification. Is my understanding correct?)

However, even after removing composing(), both 123 and 456 are assigned to --phone. (Execution on Wandbox)

On the other hand, in order to confirm the effect of composing() in the current implementation, when store() is called twice, we can see that the result changes depending on whether composing() is called or not.

Implementation Analysis

From what I've seen of the implementation of Boost 1.81.0, these lines are suspect.

  • In the first for loop to proceed the parsed options (L48-L93)
    • The condition for skipping assignment depends on xm.m_final. (L67-L68)
    • If is_composing() is false, new_final is modified. (L85-L91)
      • The comment here clearly states that composing() affects subsequent calls to store(). I think this statement has a gap with that in Example 63.2.
  • After the first for loop, xm.m_final is modified by new_final (L102)

The intuitive image from the description of Example 63.2 is an implementation in which:

  • Deleting L102.
  • Modifying L91 to xm.m_final.insert(option_name)

Summary

  • There seems to be a gap between the specification (which I can intuitively read from Example 63.2) and the implementation.
  • I would like to clarify if my understanding is wrong or if either the description of Example 63.2 or implementation is incorrect.

Version

  • Boost 1.81.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant