Re: [boost] [optional] generates unnessesary code for trivial types
But even that appears like a non-obvious thing to me. Would other people here in the list, and also developers in general agree that it is ok that you have output operation but no input operation? I think that in the standard library they always go in pairs. (I am not sure, though).
Also, how would you implement it? what should an uninitialized optional print? Nothing? but how is having printed an uninitialized
In my own code I often find myself defining only output operators. For things more complex than enums or numerics I usually handle input with specialized solutions, with tools line Boost.Spirit. As for the standard library, I'm not sure but dos thread::id have an input operator? optional<int>
different that not having printed anything? A question mark? but how would the following two be different:
If you propose to provide only output operation, then it looks like you want this for some sort of logging. But perhaps it is better to have some overloaded function toString() that converts all the types to strings. Usually the string format that works for one program does not work for
FWIW, boost::optional provides both input and output. the
other. And there appears to be no natural/intuitive way of representing any type (like optional) as text.
I usually dislike toString and alike methods. I think, manipulators are more flexible and modularized approach. Do you think it would be possible to provide different manipulators to fulfill different IO requirements?
I have checked the standard and indeed thread::id provides operator<< without the matching operator>>, so this asymmetry would not be a precedent in the standard. Although the situation with thread::id is speciffic. ID's are assigned by the OS and trying to assign them by other means would definitely be an error. I also checked boost::optional and it provides both (I learned two new things today). Uninitialized optional of any type renders "--" (two dashes); whereas initialize optional always prepends a space. I am not sure if this does not look like hack; but people already said this would not be much of a problem. Certainly, there ways to make the output of optional configurable. I am not sure manipulators would be my preference. An alternative would be the approach that Boost.Date_time has adopted: you set your preference per stream (plus one global setting) by means of locale mechanism. However, when it comes to proposing stuff in front of the ISO committee, there is one other factor, which I failed to mention yet. It is the "fragility" of the process. I am concerned that if anything turns out to be controversial, the whole Optional would be at risk of being rejected. This might be an exaggeration (I have never gone through the process of proposing something and then pushing it through), but Optional has already been proposed by Fernando (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1878.htm) and rejected; primarily for two things: operators -> and * and the semantics for optional reference assignment (see http://lists.boost.org/Archives/boost/2005/10/95079.php). I would much like to avoid the situation where Optional (which I believe is very useful to wide variety of programmers) would be rejected because of one additional, however tiny, controversy of streaming operator. Regards, &rzej
On Mon, Feb 13, 2012 at 9:51 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Certainly, there ways to make the output of optional configurable. I am not sure manipulators would be my preference. An alternative would be the approach that Boost.Date_time has adopted: you set your preference per stream (plus one global setting) by means of locale mechanism. However, when it comes to proposing stuff in front of the ISO committee, there is one other factor, which I failed to mention yet. It is the "fragility" of the process. I am concerned that if anything turns out to be controversial, the whole Optional would be at risk of being rejected. This might be an exaggeration (I have never gone through the process of proposing something and then pushing it through), but Optional has already been proposed by Fernando (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1878.htm) and rejected; primarily for two things: operators -> and * and the semantics for optional reference assignment (see http://lists.boost.org/Archives/boost/2005/10/95079.php). I would much like to avoid the situation where Optional (which I believe is very useful to wide variety of programmers) would be rejected because of one additional, however tiny, controversy of streaming operator.
I think the safe option is to not include it. Same for references. What's the problem with the ptr interface? Seems fine with me. -- Olaf
Olaf van der Spek wrote:
On Mon, Feb 13, 2012 at 9:51 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Certainly, there ways to make the output of optional configurable. [snip] However, when it comes to proposing stuff in front of the ISO committee, there is one other factor, which I failed to mention yet. It is the "fragility" of the process. I am concerned that if anything turns out to be controversial, the whole Optional would be at risk of being rejected. This might be an exaggeration (I have never gone through the process of proposing something and then pushing it through), but Optional has already been proposed by Fernando (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1878.htm) and rejected; primarily for two things: operators -> and * and the semantics for optional reference assignment (see http://lists.boost.org/Archives/boost/2005/10/95079.php). I would much like to avoid the situation where Optional (which I believe is very useful to wide variety of programmers) would be rejected because of one additional, however tiny, controversy of streaming operator.
I agree with being conservative to ensure its inclusion, but there may be a way to get both.
I think the safe option is to not include it. Same for references. What's the problem with the ptr interface? Seems fine with me.
One proposal can be for the no I/O, no reference version. Another proposal could extend that with I/O. Yet another could extend it with reference support. That would permit the first proposal to be accepted, even if the others are rejected. I think it is also reasonable to make I/O and reference support optional additions to the core of a single proposal. Obviously, I/O can be defaulted and made customizable. Deciding on widely useful defaults may not be easy, but customization does permit choosing alternatives. The easiest customization is, of course, a traits class. Reference support, with some assignment policy, can be added by a wrapper type. "optional_with_references", say, can do everything the normal optional class does plus add support for references. That's not as pretty, perhaps, but there would, then, be no question as to the behavior in a given context. Indeed, you could have two variants of the wrapper to give both assignment protocols, thereby removing all confusion. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Andrzej Krzemienski -
Olaf van der Spek -
Stewart, Robert