I'd like to make a change to the Boost Format library, to add a conversion operator to the matching string class. It appears to have not been worked on in a number of years. Reading through the web site, I find details on how to submit new libraries, and how to edit the web page, but nothing on submitting updates to existing libraries. How would I go about doing that, for this library in particular? —John
John M. Dlugosz wrote
I'd like to make a change to the Boost Format library, to add a conversion operator to the matching string class. It appears to have not been worked on in a number of years. Reading through the web site, I find details on how to submit new libraries, and how to edit the web page, but nothing on submitting updates to existing libraries.
How would I go about doing that, for this library in particular?
Hi, This http://www.boost.org/community/requests.html should help you. * Discuss the issue on the dev list * Create a ticket on the Trac System adding as much information as possible, patch containing the code modified, tests, doc, ... Best, Vicente Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Format-Making-a-change-tp4383214p4383264.... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2/13/2012 3:39 AM, Vicente Botet wrote:
This http://www.boost.org/community/requests.html should help you.
* Discuss the issue on the dev list * Create a ticket on the Trac System adding as much information as possible, patch containing the code modified, tests, doc, ...
Interestingly, that page states, "You can also try submitting a feature request to our ticket system, but experience has shown that posting to either of the mailing lists is usually a more effective way to get attention of boost developers."
Date: Mon, 13 Feb 2012 03:16:12 -0600 From: mpbecey7gu@snkmail.com
I'd like to make a change to the Boost Format library, to add a conversion operator to the matching string class. It appears to have not been worked on in a number of years. Reading through the web site, I find details on how to submit new libraries, and how to edit the web page, but nothing on submitting updates to existing libraries.
How would I go about doing that, for this library in particular?
Wasn't there recently another thread about this? If you didn't read that thread, it referredto another thread from 7 years ago about the same thing. Boost.Format already provides amember function and a free function to convert a format object to a string. The conversionsthrow if the format object hasn't had all of its parameters filled in. You want to add a thirdmethod? Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.) Daryle W.
On Tue, Feb 14, 2012 at 6:04 AM, Daryle Walker <darylew@hotmail.com> wrote:
Wasn't there recently another thread about this? If you didn't read that thread, it referredto another thread from 7 years ago about the same thing. Boost.Format already provides amember function and a free function to convert a format object to a string. The conversionsthrow if the format object hasn't had all of its parameters filled in. You want to add a thirdmethod?
Yes, please
Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.)
Why would that be bad? The conversion from format to string is well defined and used (very) frequently. It's also cumbersome at the moment. Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name); -- Olaf
On 2/14/2012 6:18 AM, Olaf van der Spek wrote:
Yes, please … Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name);
I've submitted a changed file (one line added, plus comments) as Ticket #6553. As far as I know, other threads have just complained about the lack and lamented it. So let's _do_ it already. Is there a committee, an official owner of that component, or what? How do we get that change accepted in the official build? —John
John M. Dlugosz wrote:
I've submitted a changed file (one line added, plus comments) as Ticket #6553.
It would be better to submit patches rather than modified files. To create a patch, you can use "svn diff". Plus, adding updates to the documentation and tests make your work more appealing. Regards, Michel
On Tue, Feb 14, 2012 at 4:18 AM, Olaf van der Spek <ml@vdspek.org> wrote: [...]
Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.)
Why would that be bad? The conversion from format to string is well defined and used (very) frequently. It's also cumbersome at the moment.
Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name);
I don't see a problem with 1. It makes your conversion intentions clear, and I don't find it onerous in the least. (My opinion, of course.) - Jeff
From: jeffrey.hellrung@gmail.com
On Tue, Feb 14, 2012 at 4:18 AM, Olaf van der Spek <ml@vdspek.org> wrote: [...]
Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.)
Why would that be bad? The conversion from format to string is well defined and used (very) frequently. It's also cumbersome at the moment.
Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name);
I don't see a problem with 1. It makes your conversion intentions clear, and I don't find it onerous in the least.
(My opinion, of course.)
- Jeff
Upon some reflection, neither of these look natural to me. What would look natural is the following, implemented using C++11 variadic templates (and then the return value could be a string in the first place): set(dict2, "link", boost::format("../../?q=%s", name)); Regards, Nate
On Wed, Feb 15, 2012 at 4:27 AM, Nathan Ridge <zeratul976@hotmail.com> wrote:
Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name);
I don't see a problem with 1. It makes your conversion intentions clear, and I don't find it onerous in the least.
(My opinion, of course.)
- Jeff
Upon some reflection, neither of these look natural to me.
What would look natural is the following, implemented using C++11 variadic templates (and then the return value could be a string in the first place):
set(dict2, "link", boost::format("../../?q=%s", name));
Yes, that'd be even better, but variadic templates won't be an option (for me) any time soon. -- Olaf
Nathan Ridge wrote
From: jeffrey.hellrung@
On Tue, Feb 14, 2012 at 4:18 AM, Olaf van der Spek <ml@> wrote: [...]
Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.)
Why would that be bad? The conversion from format to string is well defined and used (very) frequently. It's also cumbersome at the moment.
Compare: 1: set(dict2, "link", (boost::format("../../?q=%s") % name).str()); 2: set(dict2, "link", boost::format("../../?q=%s") % name);
I don't see a problem with 1. It makes your conversion intentions clear, and I don't find it onerous in the least.
(My opinion, of course.)
- Jeff
Upon some reflection, neither of these look natural to me.
What would look natural is the following, implemented using C++11 variadic templates (and then the return value could be a string in the first place):
set(dict2, "link", boost::format("../../?q=%s", name));
Note that Boost.Format works differently depending on the locale of the Output Stream. So, I guess your proposal is not an option. IIRC, when you use explicitly the str function you are stating explicitly that you want to use the default locale. I don't see yet why set(dict2, "link", str(format("../../?q=%s") % name)); is not satisfactory. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Format-Making-a-change-tp4383214p4390084.... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, Feb 15, 2012 at 12:16 PM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Upon some reflection, neither of these look natural to me.
What would look natural is the following, implemented using C++11 variadic templates (and then the return value could be a string in the first place):
set(dict2, "link", boost::format("../../?q=%s", name));
Note that Boost.Format works differently depending on the locale of the Output Stream. So, I guess your proposal is not an option.
Argh, those silly locales again.
IIRC, when you use explicitly the str function you are stating explicitly that you want to use the default locale.
I don't see yet why
set(dict2, "link", str(format("../../?q=%s") % name)); // 1 set(dict2, "link", format("../../?q=%s") % name); // 2
is not satisfactory.
It's still worse than 2. -- Olaf
Olaf van der Spek wrote:
On Wed, Feb 15, 2012 at 12:16 PM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Upon some reflection, neither of these look natural to me.
What would look natural is the following, implemented using C++11 variadic templates (and then the return value could be a string in the first place):
set(dict2, "link", boost::format("../../?q=%s", name));
Note that Boost.Format works differently depending on the locale of the Output Stream. So, I guess your proposal is not an option.
Argh, those silly locales again.
IIRC, when you use explicitly the str function you are stating explicitly that you want to use the default locale.
I don't see yet why
set(dict2, "link", str(format("../../?q=%s") % name)); // 1 set(dict2, "link", format("../../?q=%s") % name); // 2
is not satisfactory.
It's still worse than 2.
Which is worse than: set(dict2, "link", "../../?q=" + name); Facetiousness aside, how would wstrings be dealt with? Jeff
On Wed, Feb 15, 2012 at 2:49 PM, Jeff Flinn <Jeffrey.Flinn@gmail.com> wrote:
Argh, those silly locales again.
IIRC, when you use explicitly the str function you are stating explicitly that you want to use the default locale.
I don't see yet why
set(dict2, "link", str(format("../../?q=%s") % name)); // 1 set(dict2, "link", format("../../?q=%s") % name); // 2
is not satisfactory.
It's still worse than 2.
Which is worse than:
set(dict2, "link", "../../?q=" + name);
Yeah, hmm...
Facetiousness aside, how would wstrings be dealt with?
Same as before? -- Olaf
On 2/13/2012 11:04 PM, Daryle Walker wrote:
Wasn't there recently another thread about this? If you didn't read that thread, it referredto another thread from 7 years ago about the same thing. Boost.Format already provides amember function and a free function to convert a format object to a string. The conversionsthrow if the format object hasn't had all of its parameters filled in. You want to add a thirdmethod? Unlike int vs. double, a formatting object and a string are NOT conceptually the samething, so adding an implicit conversion would be bad. (Actually, we should limit implicitconversions in general; so converting weakly-connected types should definitely be out.) Daryle W.
Yes, I do indeed. Both forms of str require extra parens and is a bit awkward for in-place formatting of strings, in particular for error messages like the argument to an exception constructor. Would it go over well if we _removed_ the ability for ostream to take a formatter without an extra function call? After all, you could use str for that too! My impression is that the ostream use-case was thought about, but the exception case was not. I do admit that for a named string variable, initializing it using free-function str isn't too bad. —John
On Tue, Feb 14, 2012 at 1:56 PM, John M. Dlugosz <mpbecey7gu@snkmail.com> wrote:
Would it go over well if we _removed_ the ability for ostream to take a formatter without an extra function call?
Probably not. Why break old code?
After all, you could use str for that too! My impression is that the ostream use-case was thought about, but the exception case was not. I do admit that for a named string variable, initializing it using free-function str isn't too bad.
But it could be better.
I've submitted a changed file (one line added, plus comments) as Ticket #6553. As far as I know, other threads have just complained about the lack and lamented it. So let's _do_ it already. Is there a committee, an official owner of that component, or what? How do we get that change accepted in the official build?
That might a bit problematic. :p Samuel Krempp is listed as the author of that lib. -- Olaf
participants (8)
-
Daryle Walker -
Jeff Flinn -
Jeffrey Lee Hellrung, Jr. -
John M. Dlugosz -
Michel Morin -
Nathan Ridge -
Olaf van der Spek -
Vicente Botet