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?)
It seems that there are others who have a similar understanding:
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.
Description and Reproduction
Consider Example 63.2 (Execution on Wandbox)
From this description, it would seem that, conversely, without the call to
composing(), only 123 would be assigned to the--phoneoption 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, whenstore()is called twice, we can see that the result changes depending on whethercomposing()is called or not.store()withcomposing(): Execution on Wandboxstore()withoutcomposing(): Execution on WandboxImplementation Analysis
From what I've seen of the implementation of Boost 1.81.0, these lines are suspect.
xm.m_final. (L67-L68)is_composing()is false,new_finalis modified. (L85-L91)composing()affects subsequent calls tostore(). I think this statement has a gap with that in Example 63.2.xm.m_finalis modified bynew_final(L102)The intuitive image from the description of Example 63.2 is an implementation in which:
xm.m_final.insert(option_name)Summary
Version