question about C++11 guidelines
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones? I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question? Robert Ramey
On Thu, May 3, 2012 at 10:30 AM, Robert Ramey <ramey@rrsd.com> wrote:
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question?
Although I wouldn't be so sure about the "most efficient/appropriate" part, I would still use boost for several reasons. This is the code we're in control of (so if there are bugs we can fix them ASAP), we know how it works (i.e. potential pitfalls and advantages) and it's available everywhere.
On 2012-05-03 08:15, Andrey Semashev wrote:
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason. Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question? Although I wouldn't be so sure about the "most efficient/appropriate"
On Thu, May 3, 2012 at 10:30 AM, Robert Ramey <ramey@rrsd.com> wrote: part, I would still use boost for several reasons. This is the code we're in control of (so if there are bugs we can fix them ASAP), we know how it works (i.e. potential pitfalls and advantages) and it's available everywhere.
On the other hand, why did boost spend all the efforts to make these things part of the new standard if not to use them? IMHO, if the new code is targeted to C++11, it should use it. And if this exposes bugs or less efficient implementations in some compilers: Cool! It will help compiler vendors and other libraries a lot! Regards, Roland
On 5/3/2012 12:27 AM, Roland Bock wrote:
On 2012-05-03 08:15, Andrey Semashev wrote:
On Thu, May 3, 2012 at 10:30 AM, Robert Ramey <ramey@rrsd.com> wrote:
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question?
I'm going on the naive assumption that each platform will have intelligently implemented C++11 library components. If that turns out not the be the case, then I will fall back on the Boost stuff, but only as needed.
Although I wouldn't be so sure about the "most efficient/appropriate" part, I would still use boost for several reasons. This is the code we're in control of (so if there are bugs we can fix them ASAP), we
This falls into the "falling back on boost only when there is a compelling reason" bucket.
know how it works (i.e. potential pitfalls and advantages) and it's available everywhere.
As I said, I'm targeting C++11 so I'm not really worried about back-compat.
On the other hand, why did boost spend all the efforts to make these things part of the new standard if not to use them?
IMHO, if the new code is targeted to C++11, it should use it. And if this exposes bugs or less efficient implementations in some compilers: Cool! It will help compiler vendors and other libraries a lot!
Right. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Le 03/05/12 08:15, Andrey Semashev a écrit :
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason. Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question? Although I wouldn't be so sure about the "most efficient/appropriate"
On Thu, May 3, 2012 at 10:30 AM, Robert Ramey<ramey@rrsd.com> wrote: part, I would still use boost for several reasons. This is the code we're in control of (so if there are bugs we can fix them ASAP), we know how it works (i.e. potential pitfalls and advantages) and it's available everywhere.
There is an additional advantage, we can extend it intrusively to try new improvements to the standard libraries. E.g. I don't see how we can implement thread cancelation/interruption on top of the standard Thread (well I have not tried it ;-)), or shared mutex without modifying the unique_lock. I guess that there are a lot of more examples. These extensions to the standard should be stated explicitly in the documentation. IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation. Best, Vicente
On Friday 04 May 2012 07:44:56 Vicente J. Botet Escriba wrote:
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation.
Although, this is not exactly on-topic, I don't agree with you here. It is the library author's choice whether to make the library strictly a drop-in replacement for a standard component or an independent library with it's own features that in some aspects reflect the standard by historical reasons. Neither approach is a limitation or a flaw.
Le 04/05/12 08:32, Andrey Semashev a écrit :
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation. Although, this is not exactly on-topic, I don't agree with you here. It is the
On Friday 04 May 2012 07:44:56 Vicente J. Botet Escriba wrote: library author's choice whether to make the library strictly a drop-in replacement for a standard component or an independent library with it's own features that in some aspects reflect the standard by historical reasons. Neither approach is a limitation or a flaw.
Is there something wrong in stating explicitly the differences? Best, Vicente
On Friday 04 May 2012 20:03:51 Vicente J. Botet Escriba wrote:
Le 04/05/12 08:32, Andrey Semashev a écrit :
On Friday 04 May 2012 07:44:56 Vicente J. Botet Escriba wrote:
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation.
Although, this is not exactly on-topic, I don't agree with you here. It is the library author's choice whether to make the library strictly a drop-in replacement for a standard component or an independent library with it's own features that in some aspects reflect the standard by historical reasons. Neither approach is a limitation or a flaw.
Is there something wrong in stating explicitly the differences?
No, it's just those differences should not be viewed as limitations.
Le 04/05/12 22:33, Andrey Semashev a écrit :
On Friday 04 May 2012 20:03:51 Vicente J. Botet Escriba wrote:
Le 04/05/12 08:32, Andrey Semashev a écrit :
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation. Although, this is not exactly on-topic, I don't agree with you here. It is
On Friday 04 May 2012 07:44:56 Vicente J. Botet Escriba wrote: the library author's choice whether to make the library strictly a drop-in replacement for a standard component or an independent library with it's own features that in some aspects reflect the standard by historical reasons. Neither approach is a limitation or a flaw. Is there something wrong in stating explicitly the differences? No, it's just those differences should not be viewed as limitations.
Agreed when it is intentional, but not when it is a missing or partially implemented feature. For example, the standard has template <class F, class ...Args> explicit thread(F&& f, Args&&... args); Boost.Thread has not yet implemented this function completely. I see this as a limitation. The limitation could be resolved or not in a portable way, but at least on C++11 compilers the feature should be implemented in a near future. We plan to do it, but as you know we can not do everything at once ;-). Hopping this clarifies my point. Sorry for been out of topic, Vicente
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation.
If we do that then those libraries will wither and die, Boost authors should be able to continue to enhance and expand capability, possibly with a view towards the *next* standard. Besides just because the standard reflects best practice right now, that doesn't mean that future tricks won't come along that improve things further. John.
Le 04/05/12 10:18, John Maddock a écrit :
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation.
If we do that then those libraries will wither and die, Boost authors should be able to continue to enhance and expand capability, possibly with a view towards the *next* standard. Besides just because the standard reflects best practice right now, that doesn't mean that future tricks won't come along that improve things further.
I don't see how my point of view disable to enhance the capacity of the library. Replace if you want "describe explicitly as a limitation" by "describe explicitly the differences. Best, Vicente
on Fri May 04 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 04/05/12 10:18, John Maddock a écrit :
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should
either be fixed or described explicitly as a limitation on the documentation.
If we do that then those libraries will wither and die, Boost authors should be able to continue to enhance and expand capability, possibly with a view towards the *next* standard. Besides just because the standard reflects best practice right now, that doesn't mean that future tricks won't come along that improve things further.
I don't see how my point of view disable to enhance the capacity of the library. Replace if you want "describe explicitly as a limitation" by "describe explicitly the differences.
I think it comes down to a difference in interpretation of "any deviation." IIUC, you meant to allow pure extensions, but John didn't read it that way. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Le 05/05/12 14:08, Dave Abrahams a écrit :
on Fri May 04 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
Le 04/05/12 10:18, John Maddock a écrit :
IMO, every Boost library that has a counterpart in the standard should comply with the standard as much as possible and should use the standard whenever it is possible (that is the class/function is available and the library don't introduce extensions on them). Any deviation from the standard could be seen as a defect and should either be fixed or described explicitly as a limitation on the documentation. If we do that then those libraries will wither and die, Boost authors should be able to continue to enhance and expand capability, possibly with a view towards the *next* standard. Besides just because the standard reflects best practice right now, that doesn't mean that future tricks won't come along that improve things further.
I don't see how my point of view disable to enhance the capacity of the library. Replace if you want "describe explicitly as a limitation" by "describe explicitly the differences. I think it comes down to a difference in interpretation of "any deviation." IIUC, you meant to allow pure extensions, but John didn't read it that way.
Yes, you understood correctly. "any deviation" was too strong. Thanks for clarifying my concern, Vicente
---- Message d'origine ----
De : "Robert Ramey" <ramey@rrsd.com> À : boost@lists.boost.org Objet : Re: [boost] question about C++11 guidelines Date : 03/05/2012 08:30:06 CEST
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Isn't easier to just use the boost versions knowing that they will be implemented in the most efficient/appropriate way for the compiler in question?
From what I understood, std::make_shared is more efficiently implemented on some platforms that boost::make_shared, so I would not assume that boost version is better than the version provided by the compiler. From a boost user point of view, I have another issue with boost compatibility with C++11, that is not used by either proposal: - If types such as boost::shared_ptr and boost::tuple are used in the library boost.sampleLib, whenever I want to interface boost.sampleLib with other code that was written without boost, and makes use of std::shared_ptr or std::tuple, I have troubles, and need to convert/copy objects - If types such as std::shared_ptr and std::tuple are used in the library boost.sampleLib, whenever I want to interface boost.sampleLib with other code that was written with boost, and makes use of boost::shared_ptr or boost::tuple, I have troubles, and need to convert/copy objects The more I think of it, the more I believe the right solution is not to have two different types, but making sure that on a platform where std::shared_ptr exists, boost::shared_ptr is defined as an alias to std::shared_ptr, and just the same for all C++11 types that were first developped with boost. Frankly, I have been using boost on VC10 that contains std::shared_ptr for quite some time now, and I can say it is quite a pain, there are many subtle compilation problems that all come down to the fact that there are duplicated types with the same name in the same program. For instance: struct A { A(int i); A(std::vector<int> const &v); }; using boost::make_shared; std::vector<int> v; boost::shared_ptr<A> p1 = make_shared<A> (3); // Works boost::shared_ptr<A> p1 = make_shared<A> (v); // Does not work, there is no conversion from std::shared_ptr to boost::shared_ptr -- Loïc
Le 03/05/12 11:15, loic.actarus.joly@numericable.fr a écrit :
---- Message d'origine ---- >De : "Robert Ramey"<ramey@rrsd.com> >À : boost@lists.boost.org >Objet : Re: [boost] question about C++11 guidelines >Date : 03/05/2012 08:30:06 CEST > >Eric Niebler wrote: > > Say I'm rewriting an existing Boost library and targeting C++11 > > users. I plan to ship C++03 and C++11 versions of my library > > side-by-side, so back-compat isn't an issue for the new code. Is > > there a reason to prefer using Boost's versions of utilities like > > enable_if, type traits, integral constant wrappers (e.g. mpl::int_), > > tuples, etc., over the now-standard ones? > > > > I'm leaning toward using std:: where I can, and falling back on > > Boost's versions only when there is a compelling reason. > > Isn't easier to just use the boost versions knowing that they > will be implemented in the most efficient/appropriate way > for the compiler in question? > From what I understood, std::make_shared is more efficiently implemented on some platforms that boost::make_shared, so I would not assume that boost version is better than the version provided by the compiler. From a boost user point of view, I have another issue with boost compatibility with C++11, that is not used by either proposal: - If types such as boost::shared_ptr and boost::tuple are used in the library boost.sampleLib, whenever I want to interface boost.sampleLib with other code that was written without boost, and makes use of std::shared_ptr or std::tuple, I have troubles, and need to convert/copy objects
Yes, this is an issue that merits a better solution.
- If types such as std::shared_ptr and std::tuple are used in the library boost.sampleLib, whenever I want to interface boost.sampleLib with other code that was written with boost, and makes use of boost::shared_ptr or boost::tuple, I have troubles, and need to convert/copy objects The more I think of it, the more I believe the right solution is not to have two different types, but making sure that on a platform where std::shared_ptr exists, boost::shared_ptr is defined as an alias to std::shared_ptr, and just the same for all C++11 types that were first developped with boost. Frankly, I have been using boost on VC10 that contains std::shared_ptr for quite some time now, and I can say it is quite a pain, there are many subtle compilation problems that all come down to the fact that there are duplicated types with the same name in the same program. For instance: struct A { A(int i); A(std::vector<int> const&v); }; using boost::make_shared; std::vector<int> v; boost::shared_ptr<A> p1 = make_shared<A> (3); // Works boost::shared_ptr<A> p1 = make_shared<A> (v); // Does not work, there is no conversion from std::shared_ptr to boost::shared_ptr --
Where std::make_shared is used here? Best, Vicente
On 03/05/12 11:15, loic.actarus.joly@numericable.fr wrote:
For instance: struct A { A(int i); A(std::vector<int> const&v); }; using boost::make_shared; std::vector<int> v; boost::shared_ptr<A> p1 = make_shared<A> (3); // Works boost::shared_ptr<A> p1 = make_shared<A> (v); // Does not work, there is no conversion from std::shared_ptr to boost::shared_ptr
No such error message here.
----- Mail original -----
De: "Eric Niebler" <eric@boostpro.com> À: "Boost mailing list" <boost@lists.boost.org> Envoyé: Jeudi 3 Mai 2012 00:01:52 Objet: [boost] question about C++11 guidelines
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
What about this ? 1) If Foo is a Boost library, it should use boost::shared_ptr. 2) boost::shared_ptr may be an alias/using/... to std::shared_ptr. But this is up to Boost.SmartPtr, not to Boost.Foo. Regards, Ivan
----- Mail original -----
De: "Andrey Semashev" <andrey.semashev@gmail.com> À: boost@lists.boost.org Envoyé: Jeudi 3 Mai 2012 10:48:45 Objet: Re: [boost] question about C++11 guidelines
What about this ?
1) If Foo is a Boost library, it should use boost::shared_ptr. 2) boost::shared_ptr may be an alias/using/... to std::shared_ptr. But this is up to Boost.SmartPtr, not to Boost.Foo.
AFAIR, not all boost libraries are equivalent to the standard counterparts.
IMHO, If boost::bar cannot be based on std::bar, whatever "based on" means, Boost.Bar decides so. Regardless, Boost should consider boost::bar as the default, or consider deprecating Boost.Bar. Now if Boost.Foo needs a feature that boost::bar cannot implement, it should use whatever suits including std::bar. Obviously. But this is not the point of the thread, IIUC. Regards, Ivan
ivan.lelann@free.fr writes:
----- Mail original -----
De: "Eric Niebler" <eric@boostpro.com> ?: "Boost mailing list" <boost@lists.boost.org> Envoy?: Jeudi 3 Mai 2012 00:01:52 Objet: [boost] question about C++11 guidelines
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
What about this ?
1) If Foo is a Boost library, it should use boost::shared_ptr. 2) boost::shared_ptr may be an alias/using/... to std::shared_ptr. But this is up to Boost.SmartPtr, not to Boost.Foo.
My experience with opaque aliasing of std and boost components is rather bad. There are some subtle differences (e.g. reference_wrapper as a functor, mem_fn and proxies, tuple operator<<, hash), naming incompatibilities, and you always need to test both configurations. It isn't worth the trouble in my experience.
On 2 May 2012 23:01, Eric Niebler <eric@boostpro.com> wrote:
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
I'll only comment on my libraries. For unordered containers, my advice is to use the standard versions if they're up to scratch. They have some implementation advantages over the boost version, and it's a good idea for everyone to settle on the same version. With boost::hash or std::hash, it's a little less clear cut, since boost::hash does a bit more than the standard version. If anyone wishes to use boost::hash with the standard unordered containers, C++11 template aliases will make that a lot easier.
Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
If every Boost component on which you relied had a C++11 mode, whereby it was just an alias for the corresponding standard component, then you could use the Boost components because clients could be sure to get standard only code when they want it, or switch off C++11 mode and get the Boost compatibility versions where necessary. That way, those wanting pure, standardized C++11 code could get it, while those without a suitable platform, can still use your library. The problem is that few, if any, Boost components are fully compatible with their standard counterparts and provide such a switchable design. Therefore, it seems that a C++11-only library should use only standard components. If those components are insufficient, I'd go so far as to say that C++11-only Boost components should be created to fill the gaps. IOW, once you head down the C++11-only path, you should not pollute it with C++98/03 noise. Otherwise, you may as well stay on the Boost-based compatibility path. _____ 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.
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities. Boost provides existing practice and reference implementations to aid in the standardization process. But we don't actually realize the benefits of standardizing Boost components if we never move off our own reference implementations. If there is a problem with a vendor's implementation of these std:: facilities, we should help that vendor get the implementation right. - Doug
Doug Gregor wrote:
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities.
Boost provides existing practice and reference implementations to aid in the standardization process. But we don't actually realize the benefits of standardizing Boost components if we never move off our own reference implementations. If there is a problem with a vendor's implementation of these std:: facilities, we should help that vendor get the implementation right.
But was a library author do in the meantime? How does one make on body of code which works on all platforms? To me the best would be that libraries make their requirements more explicit. Something like: library X Presumes C++11 compatibility library Y presumes C++03 compatibility Of course in practice since no compiler actually supports the above statements would have to be modifed to: library X : works with compiler A, B, C & D with the C++11 switch on library Y : works with compiler I, J, K, ... Which is more or less the situation we have now. Basically a library author has to decide which group of compilers he's going to support. Some libraries need to be almost universal (e.g. shared_ptr) while others don't have to be (e.g. fusion) since they're audience is more narrow. Robert Ramey
On Thu, May 3, 2012 at 12:27 PM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities.
Boost provides existing practice and reference implementations to aid in the standardization process. But we don't actually realize the benefits of standardizing Boost components if we never move off our own reference implementations. If there is a problem with a vendor's implementation of these std:: facilities, we should help that vendor get the implementation right.
Long term, +1. Shorter term, individual libraries probably need to ease into this to see what issues come up. --Beman
----- Mail original -----
De: "Doug Gregor" <doug.gregor@gmail.com> À: boost@lists.boost.org Envoyé: Jeudi 3 Mai 2012 18:27:31 Objet: Re: [boost] question about C++11 guidelines
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities.
Obviously but the problem is what "use" means. It's not because you call it "boost::shared_ptr" that it does not use, alias or wrap C++11. And boost::shared_ptr and boost::enable_if may be new beasts in the future. If you wrote std::shared_ptr and std::enable_if everywhere in your code, you won't be able to benefit from that. Typically, today, you cannot have Boost use Boost.Container by default because you see std::vector and std::string in all Boost code ... Regards, Ivan
On May 4, 2012, at 1:53 AM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
----- Mail original -----
De: "Doug Gregor" <doug.gregor@gmail.com> À: boost@lists.boost.org Envoyé: Jeudi 3 Mai 2012 18:27:31 Objet: Re: [boost] question about C++11 guidelines
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities.
Obviously but the problem is what "use" means. It's not because you call it "boost::shared_ptr" that it does not use, alias or wrap C++11.
And boost::shared_ptr and boost::enable_if may be new beasts in the future.
That would be unfortunate. The whole point of standardization is to get everyone to use the same components with the same features. If we go off and extend boost::shared_ptr to make it different from std::shared_ptr, we've done the C++ community a double disservice because we ourselves have created two de facto standards for shared_ptr: the actual standard and Boost itself.
If you wrote std::shared_ptr and std::enable_if everywhere in your code, you won't be able to benefit from that.
Or be hurt by it. It's time to leave the already-standardized Boost components' interfaces alone. Whatever little advantages we get from further improvements are wiped out by the disadvantages of continued fragmentation. Besides, aren't there a thousand other libraries to build and improve? ;) - Doug
on Thu May 03 2012, Doug Gregor <doug.gregor-AT-gmail.com> wrote:
On Wed, May 2, 2012 at 3:01 PM, Eric Niebler <eric@boostpro.com> wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Boost in C++11 should use the std:: facilities.
Boost provides existing practice and reference implementations to aid in the standardization process. But we don't actually realize the benefits of standardizing Boost components if we never move off our own reference implementations. If there is a problem with a vendor's implementation of these std:: facilities, we should help that vendor get the implementation right.
+1, but what about additional features? Some of the libraries we have implemented offer new features that aren't available in the standard versions. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 03/05/12 00:01, Eric Niebler wrote:
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones?
I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
Some C++11-capable compilers do not ship with C++11-enabled standard libraries.
Le 03/05/12 00:01, Eric Niebler a écrit :
Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Good idea. I think that is the way to go that allows a good refactoring taking in account the best of C++11.
Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones? I don't see any if the standard provides you whatever you need. I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason.
This seems reasonable. Best, Vicente
participants (16)
-
Andrey Semashev -
Beman Dawes -
Daniel James -
Dave Abrahams -
Doug Gregor -
Eric Niebler -
Ivan Le Lann -
ivan.lelann＠free.fr
-
John Maddock -
loic.actarus.joly＠numericable.fr -
Mathias Gaunard -
Philipp Moeller -
Robert Ramey -
Roland Bock -
Stewart, Robert -
Vicente J. Botet Escriba