Potential project: Resolving boost::chrono conflicts with std::chrono

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
Possible project for someone looking for a boost project to contribute to:

boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11.  Fast forward 8 years:  Now we have two competing chrono libraries:  boost::chrono and std::chrono.  And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono.  Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono.  And these errors often come from deep within libraries which people are simply trying to use.

The pitch:  boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later.  This would make boost significantly easier to use.  This is likely a multi-project effort, and I don’t even have a concrete strategy in mind.  This is a problem in search of a solution, not vice-versa.  And I often hear of enthusiastic people who want to jump in and lend a helping hand.  I think this would be a terrific area to point such talent towards.

Howard



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts withstd::chrono

Boost - Dev mailing list
Hey @Howard Hinnant I would surely like to contribute towards this potential project. I too agree that std::chrono has much better compiler support and is supported by almost all modern compilers and also has better overall support. However I think we must not deprecate boost::chrono as it provides users with additional functionality which std::chrono lacks. So we may reimplement boost::chrono in terms of std::chrono. What do you think?

Thanks!
Atharva

From: Howard Hinnant via Boost
Sent: 09 August 2019 06:31
To: [hidden email]
Cc: Howard Hinnant
Subject: [boost] Potential project: Resolving boost::chrono conflicts withstd::chrono

Possible project for someone looking for a boost project to contribute to:

boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11.  Fast forward 8 years:  Now we have two competing chrono libraries:  boost::chrono and std::chrono.  And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono.  Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono.  And these errors often come from deep within libraries which people are simply trying to use.

The pitch:  boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later.  This would make boost significantly easier to use.  This is likely a multi-project effort, and I don’t even have a concrete strategy in mind.  This is a problem in search of a solution, not vice-versa.  And I often hear of enthusiastic people who want to jump in and lend a helping hand.  I think this would be a terrific area to point such talent towards.

Howard



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 9 Aug 2019 at 04:01, Howard Hinnant via Boost <[hidden email]>
wrote:

> The pitch:  boost::chrono, and other boost::libs needs to defer to
> std::chrono for C++11 and later.
>

This library by Edward achieves the above not only for boost::chrono, but
Boost-wide: https://github.com/eldiener/cxx_dual . From the date of the
last commit, one can deduce, though, that this does not cover C++17 [but
that might not be so urgent/relevant].

Docs: https://eldiener.github.io/cxx_dual/doc/html/index.html .

degski
--
@realdegski
https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
Am 09.08.19 um 08:23 schrieb degski via Boost:

> On Fri, 9 Aug 2019 at 04:01, Howard Hinnant via Boost <[hidden email]>
> wrote:
>
>> The pitch:  boost::chrono, and other boost::libs needs to defer to
>> std::chrono for C++11 and later.
>>
> This library by Edward achieves the above not only for boost::chrono, but
> Boost-wide: https://github.com/eldiener/cxx_dual . From the date of the
> last commit, one can deduce, though, that this does not cover C++17 [but
> that might not be so urgent/relevant].
>
> Docs: https://eldiener.github.io/cxx_dual/doc/html/index.html .
As it was often discussed for Boost to "switch to C++11", why burden the
maintainers with the old cruft?

My proposal would be: Implement Boost.Chrono in terms of std::chrono.
(Just seen Atharva said the same)
This requires:
- Identify differences
- Replace Boost.Chrono types with typedefs to same std::chrono types (or
maybe just using namespace std::chrono inside boost::chrono?)
- Adapt functions only contained in Boost.Chrono

As to "dropping C++98 compatibility" I repeat previous arguments:
- People using latest Boost probably don't use pre-C++11 compilers
- No guarantee about C++98-compatibility was ever made, each library is
free to drop such support at any point
- This support would trickle down to dependent libraries

On the proposed alternative via cxxd: This won't work. If Boost
internals use CXXD they will end up using either std::chrono or
boost::chrono which will result in API and/or ABI incompatibility.
Compare this to scoped enum usage in Boost.Filesystem in the API which
made the library compiled in pre-C++11 mode unusable to user code in
post-C++11 code (and vice versa) and required subsequent fixes to
work-around that.

Alex




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/9/2019 2:23 AM, degski via Boost wrote:

> On Fri, 9 Aug 2019 at 04:01, Howard Hinnant via Boost <[hidden email]>
> wrote:
>
>> The pitch:  boost::chrono, and other boost::libs needs to defer to
>> std::chrono for C++11 and later.
>>
>
> This library by Edward achieves the above not only for boost::chrono, but
> Boost-wide: https://github.com/eldiener/cxx_dual . From the date of the
> last commit, one can deduce, though, that this does not cover C++17 [but
> that might not be so urgent/relevant].

If there is something added in C++17 that affects using cxx_dual I would
love to hear about it, but I doubt that is presently the case.

>
> Docs: https://eldiener.github.io/cxx_dual/doc/html/index.html .
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/9/2019 2:48 AM, Alexander Grund via Boost wrote:

> Am 09.08.19 um 08:23 schrieb degski via Boost:
>> On Fri, 9 Aug 2019 at 04:01, Howard Hinnant via Boost
>> <[hidden email]>
>> wrote:
>>
>>> The pitch:  boost::chrono, and other boost::libs needs to defer to
>>> std::chrono for C++11 and later.
>>>
>> This library by Edward achieves the above not only for boost::chrono, but
>> Boost-wide: https://github.com/eldiener/cxx_dual . From the date of the
>> last commit, one can deduce, though, that this does not cover C++17 [but
>> that might not be so urgent/relevant].
>>
>> Docs: https://eldiener.github.io/cxx_dual/doc/html/index.html .
>
> As it was often discussed for Boost to "switch to C++11", why burden the
> maintainers with the old cruft?
>
> My proposal would be: Implement Boost.Chrono in terms of std::chrono.
> (Just seen Atharva said the same)
> This requires:
> - Identify differences
> - Replace Boost.Chrono types with typedefs to same std::chrono types (or
> maybe just using namespace std::chrono inside boost::chrono?)
> - Adapt functions only contained in Boost.Chrono
>
> As to "dropping C++98 compatibility" I repeat previous arguments:
> - People using latest Boost probably don't use pre-C++11 compilers
> - No guarantee about C++98-compatibility was ever made, each library is
> free to drop such support at any point
> - This support would trickle down to dependent libraries
>
> On the proposed alternative via cxxd: This won't work. If Boost
> internals use CXXD they will end up using either std::chrono or
> boost::chrono which will result in API and/or ABI incompatibility.

Unless a library uses different public/protected functionality based on
the choice between boost::chrono or std::chrono there will be no API
incompatibility for the library itself. As far as ABI incompatibility I
discuss in the cxxd docs how a shared library can produce different
versions based on the cxxd choice for a dual library. For header-only
libraries, which is a good part of Boost, ABI incompatibility does not
exist AFAICS, but maybe I am missing what you mean when you say that.

> Compare this to scoped enum usage in Boost.Filesystem in the API which
> made the library compiled in pre-C++11 mode unusable to user code in
> post-C++11 code (and vice versa) and required subsequent fixes to
> work-around that.
>
> Alex
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 9 Aug 2019 at 10:11, Alexander Grund via Boost <
[hidden email]> wrote:

> As it was often discussed for Boost to "switch to C++11", why burden the
> maintainers with the old cruft?
>

Did you read
https://eldiener.github.io/cxx_dual/doc/html/index.html#cxxd.introduction ?
This library is designed with the specific purpose of NOT burden
maintainers with 'old cruft'. Having said that, the 'old cruft' is in those
Boost libraries, not in the std.

degski
--
@realdegski
https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 9 Aug 2019 at 11:58, Edward Diener via Boost <[hidden email]>
wrote:

> If there is something added in C++17 that affects using cxx_dual I would
> love to hear about it, but I doubt that is presently the case.
>

Edward, I did not (intend to) say that. I was just noting that the last
commit seems to be around the time of C++14. It is good to hear from you
and you stating that in reality, cxx_dual is still a perfectly viable
solution to OP's problem, also with C++17. I think cxx_dual should be part
of Boost, but we went through that discussion already.

degski
--
@realdegski
https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/9/19 3:01 AM, Howard Hinnant via Boost wrote:

> The pitch:  boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later.  This would make

This should be done with great care.

Boost.Asio does exactly this for its timer classes -- use boost::chrono
if compiled pre-C++11 and otherwise use std::chrono.

As implemented, this is a pain from the users perspective, because the
user has to pass a type-strong expiration parameter which can be either,
say, std::chrono::seconds or boost::chrono::seconds. This means, that
your code that works perfectly suddenly yields compilation errors when
your users change the compiler flags.

   boost::asio::steady_timer timer;
   timer.expires_from_now(boost::chrono::seconds(5)); // Fails post C++03

The Boost.Asio way is to import all chrono symbols into its own
namespace:

   boost::asio::steady_timer timer;
   timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay

Another solution is to use the timer template classes, e.g.
basic_waitable_timer instead of steady_timer, so the user can work
around the problem by selecting whether to use std::chrono or
boost::chrono:

   boost::asio::basic_waitable_timer<boost::chrono::steady_clock> timer;
   timer.expires_from_now(boost::chrono::seconds(5)); // Okay

PS: I am not arguing for or against the project, nor am I recommending
any particular solution. I am just sharing some experience.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 09.08.19 um 11:33 schrieb degski via Boost:
>
> This library is designed with the specific purpose of NOT burden maintainers with 'old cruft'.

And also

 >Unless a library uses different public/protected functionality based
on the choice between boost::chrono or std::chrono there will be no API
incompatibility for the library itself. As far as ABI incompatibility I
discuss in the cxxd docs how a shared library can produce different
versions based on the cxxd choice for a dual library. For header-only
libraries, which is a good part of Boost, ABI incompatibility does not
exist AFAICS, but maybe I am missing what you mean when you say that.

And also

 > Boost.Asio does exactly this for its timer classes -- use
boost::chrono if compiled pre-C++11 and otherwise use std::chrono.

 > As implemented, this is a pain from the users perspective

To summarize: Boost.Asio does basically what cxxd does: Wrap either
namespace in its own. And it has to go some lengths to make this work.

And the mentioned approach of generating variants depending on which ABI
is generated would be an even larger pain for the users. Now among all
those variants for debug/release, static/shared runtime, static/shared
boost, version, ... now there will also be variants depending on the
chrono used (or C++ standard used). This IS a burden compared to:
`boost::chrono == std::chrono with utility functions` (not sure what
boost provides over the std) The discussed use of `auto_link` does not
work for the majority (Linux, CMake, ...)

And for header-only libs: You still have the problem, that (apparently)
Boost.Chrono offers functionality which is a superset of std::chrono
which you won't be able to use. Example:
`boost::chrono::do_cool_thing(cxxd::chrono::hours(42))`. If cxxd==std
then `do_cool_thing` might not work as it expects a `boost::chrono::hours`




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> The Boost.Asio way is to import all chrono symbols into its own
> namespace:
>
>   boost::asio::steady_timer timer;
>   timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay
>
> PS: I am not arguing for or against the project, nor am I recommending
> any particular solution. I am just sharing some experience.

I use the local namespace bind approach in my own libraries. Then people
do nialllib::filesystem::path, or whatever.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/9/2019 8:11 AM, Alexander Grund via Boost wrote:

> Am 09.08.19 um 11:33 schrieb degski via Boost:
>>
>> This library is designed with the specific purpose of NOT burden
>> maintainers with 'old cruft'.
>
> And also
>
>  >Unless a library uses different public/protected functionality based
> on the choice between boost::chrono or std::chrono there will be no API
> incompatibility for the library itself. As far as ABI incompatibility I
> discuss in the cxxd docs how a shared library can produce different
> versions based on the cxxd choice for a dual library. For header-only
> libraries, which is a good part of Boost, ABI incompatibility does not
> exist AFAICS, but maybe I am missing what you mean when you say that.
>
> And also
>
>  > Boost.Asio does exactly this for its timer classes -- use
> boost::chrono if compiled pre-C++11 and otherwise use std::chrono.
>
>  > As implemented, this is a pain from the users perspective
>
> To summarize: Boost.Asio does basically what cxxd does: Wrap either
> namespace in its own. And it has to go some lengths to make this work.

Obviously cxxd does not have to go to great lengths to make this work
for the end-user, as it is already done for a number of dual libraries,
and the end-user just has includes the correct cxxd header file for the
correct dual library. For chrono the header file is
'boost/cxx_dual/chrono.hpp'.

>
> And the mentioned approach of generating variants depending on which ABI
> is generated would be an even larger pain for the users. Now among all
> those variants for debug/release, static/shared runtime, static/shared
> boost, version, ... now there will also be variants depending on the
> chrono used (or C++ standard used).

I agree with you that designing variant shared libraries is complicated.
But it is what all shared libraries do if they want to give the end-user
choices of what they want, as you specify above. But I do get your point.

> This IS a burden compared to:
> `boost::chrono == std::chrono with utility functions` (not sure what
> boost provides over the std)

So you want to all Boost libraries which currently support boost::chrono
to also support std::chrono in c++11 mode or higher with additional
interfaces for using std::chrono ? Sure, go ahead if you think that is
viable. That's what everybody currently does now anyway. I personally do
not relish that sort of work, which is why I created cxxd in the first
place.

> The discussed use of `auto_link` does not
> work for the majority (Linux, CMake, ...)

You can depend or not depend on auto-link whether you use cxxd or not.
Without cxxd you still have to instruct the end-user how to link a
shared library if autolink is not available. It would be no different
with using cxxd, except that you will have more shared library variant
names to tell the end-user about to do his manual linking.

>
> And for header-only libs: You still have the problem, that (apparently)
> Boost.Chrono offers functionality which is a superset of std::chrono
> which you won't be able to use. Example:
> `boost::chrono::do_cool_thing(cxxd::chrono::hours(42))`. If cxxd==std
> then `do_cool_thing` might not work as it expects a `boost::chrono::hours`

Using cxxd you can still write one-off compile time code which depends
on which dual library is being used, either boost::chrono or std::chrono
in this particular case. A preprocessor macro ( CXXD_HAS_STD_CHRONO in
our case ) is available for each dual library  which tells the end-user
at compile time which choice is being made, so writing one-off code
based on that macro is easy enough.

The idea of cxxd is that writing occasional one-off code, while using
the exact same syntax for the majority of your code, is much easier to
do than writing completely separate code, which does the exact same
thing in the vast majority of cases, for each public/protected interface
which uses a particular dual library choice.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
 > Obviously cxxd does not have to go to great lengths to make this work
for the end-user,

Just picked this quote but it applies to more: The use-case for cxxd is
another than what is intended for a boost-wide solution. As you write
yourself: It is great for one-off code.
In most projects using Boost you don't manually link a boost lib, but
use CMake (or similar). Having more variants means more switches and
complicate the process

 >So you want to all Boost libraries which currently support
boost::chrono to also support std::chrono in c++11 mode or higher with
additional interfaces for using std::chrono ? Sure, go ahead if you
think that is viable. That's what everybody currently does now anyway. I
personally do not relish that sort of work, which is why I created cxxd
in the first place.

No. What I and Atharva propose is essentially: `namespace boost::chrono{
using namespace std::chrono; }`. All libraries which use boost::chrono
will now automatically work with std::chrono and users can use
boost::chrono or std::chrono to call into any boost library.

The idea is: (Almost?) all types in std::chrono have exact equivalents
in boost which can simply be used and the boost types can be removed.
Additional functionality provided by Boost (if there is any) should be
changed to rely on std::chrono types (if they even need to, due to the
aliasing above)

What I added was to NOT provide alternatives to C++11 and simply require
them which avoids the need to create variants for the different standards.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
On 8/9/2019 9:57 AM, Alexander Grund via Boost wrote:

>  > Obviously cxxd does not have to go to great lengths to make this work
> for the end-user,
>
> Just picked this quote but it applies to more: The use-case for cxxd is
> another than what is intended for a boost-wide solution. As you write
> yourself: It is great for one-off code.
> In most projects using Boost you don't manually link a boost lib, but
> use CMake (or similar). Having more variants means more switches and
> complicate the process
>
>  >So you want to all Boost libraries which currently support
> boost::chrono to also support std::chrono in c++11 mode or higher with
> additional interfaces for using std::chrono ? Sure, go ahead if you
> think that is viable. That's what everybody currently does now anyway. I
> personally do not relish that sort of work, which is why I created cxxd
> in the first place.
>
> No. What I and Atharva propose is essentially: `namespace boost::chrono{
> using namespace std::chrono; }`. All libraries which use boost::chrono
> will now automatically work with std::chrono and users can use
> boost::chrono or std::chrono to call into any boost library.

As long as there is no difference in functionality between boost::chrono
and std::chrono, and as long as boost:;chrono is fine with being a C++11
on up library, your technique as specified above should work. But in
that case we might as well tell end-users about it and that they might
want to transition directly to std::chrono and stop using boost::chrono.

>
> The idea is: (Almost?) all types in std::chrono have exact equivalents
> in boost which can simply be used and the boost types can be removed.
> Additional functionality provided by Boost (if there is any) should be
> changed to rely on std::chrono types (if they even need to, due to the
> aliasing above)

If there is additional functionality in boost::chrono that is not in
std::chrono it probably can not rely on std::chrono to provide it.
Furthermore if there is additional functionality in std::chrono that is
not in boost::chrono your technique will expose it to users of
boost::chrono, and they would need to be told about it in the docs.

>
> What I added was to NOT provide alternatives to C++11 and simply require
> them which avoids the need to create variants for the different standards.

Sure, because with your suggested change you are assuming a standard of
C++11 on up for boost::chrono and all Boost libraries which use
boost::chrono.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflictswithstd::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Imagine that there is a legacy(maybe) code running with boost and we are suddenly saying that we no longer support boost and that you have to change to std. This will be so much pain for end users. So instead what we are doing is not making end users go through pain by reimplementing boost in terms of std and in return we will have to do a little hard-work. (By doing so we would have honed our skills and helped the community with stable chrono. Win-win for everyone.)

Mr. Howard Hinnant might have envisioned that boost has served its purpose and its time for it to retire. Think of it in this way, after this task this library will require zero or very little maintenance as its using std. The only time maybe if there are changes to upstream std then we need to maintain boost which I think would be after so many years.

Also I would like to remind that boost is superset of std (there might be something that might have slipped my eyes but I think we can take care of it)

Also I have seen end users heavily modifying boost since its open source. So I think reimplementation of boost in terms of std will give them a clean understandable code which they can modify very easily.

We can also mark the entire doc as deprecated (except the {boost}-{std} part).
Boost was always about cutting edge libs for developers and end users.

Thanks! To all for such a great discussion.
If during discussions I might have hurt someone, sorry for that!
I think we should brainstorm a little bit.

Thanks!
Atharva Veer

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/8/19 6:01 PM, Howard Hinnant via Boost wrote:
> Possible project for someone looking for a boost project to contribute to:
>
> boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11.  Fast forward 8 years:  Now we have two competing chrono libraries:  boost::chrono and std::chrono.  And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono.  Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono.  And these errors often come from deep within libraries which people are simply trying to use.
>

I'm wondering if given the existence of a boost and std version of the
same library, it might be better policy to prefer the boost version.

The boost version is one body of source code which is portable across
C++ versions 11 or newer.  The std version is supplied by the compiler
vendor.  Each one makes his own version which has it's own quirks,
interpretations of ambiguities the standard, etc. The probability that
there are not hidden, subtle differences between them is very small.
Each vendor creates his own test suite (I presume) which as users, we
aren't privy to.  So when something goes haywire, we can't just run the
test suite - we have to embark on very long cat and mouse game.

And not all vendors provide documentation of their libraries.

A standard is released and the distinct compiler vendors don't provide
all the new libraries at the same time.  So we have to include a bunch
of code on our libraries which determine which aspects of C++ supported
by which vendors compiler.  Boost Config does a great job.  But it's
still a nightmare.

It's inexplicable to me why vendors make their own (often inferior)
versions of the boost library versions.  Have they nothing better to do
with their money?  If they want, the could send some my way.

The only real motivation for using the std versions is to address the
C++ dependency/deployment problems - which no one as really thought
enough about yet.

Back to the original point, seems to be that the best policy would be:
If the same library is in boost and the std library, one should prefer
the boost version.

Robert Ramey




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
Robert Ramey via Boost said:     (by the date of Fri, 9 Aug 2019 22:48:59 -0700)

> I'm wondering if given the existence of a boost and std version of the
> same library, it might be better policy to prefer the boost version.

I agree 100%. Also this is the approach which I recommend to my
students. Although my reasoning was a little different. I did not
focus on std:: implementation discrepancies between various vendors.
I rather emphasized fact that boost is always at least 5 years ahead
of the standard. And most likely you need a feature now, rather than
wait 5 years. Then in 5 years you have plenty of code which already
uses boost. No need to reorganize it now and switch it to std::



best regards
Janek Kozicki

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Aug 10, 2019, at 1:48 AM, Robert Ramey via Boost <[hidden email]> wrote:
>
> It's inexplicable to me why vendors make their own (often inferior) versions of the boost library versions.  Have they nothing better to do with their money?  If they want, the could send some my way.

In the case of <chrono>, std::chrono came first, at least in implementation in libc++.

In other cases, corporate policy may not accept the boost copyright.

And in other cases, a std::lib maintainer may feel the need to become expert in the subject matter since he/she will be at the tip of the spear in supporting it.

Though multiple implementations has its down side, it also has its upsides, such as better chances at minor improvements, both in API and performance.  Independent implementations are also an excellent technique for improving the specification.

Howard



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list
In case it wasn't obvious, this is one more bullet in my campaign to see
the standards committee narrow it's scope to the things that only such a
committee can do. That is:

a) core language syntax and semantics
b) core libraries which place a common interface on underlying machine
or operating system implementations

Other stuff should be considered separately.  Preferably by some other
organization but at least by a separate committee. The current structure
is failing to scale and the problem is growing (exponentially?). I'm
sorry I continue to harp on this, but I'm not getting traction.  Note
that a huge portion of standard libraries have their origin in other
organizations - stl, boost, and others.  The committee has a poor track
record in delivering quality libraries in a timely manner.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Potential project: Resolving boost::chrono conflicts with std::chrono

Boost - Dev mailing list

On 8/10/19 1:51 PM, Robert Ramey via Boost wrote:

> In case it wasn't obvious, this is one more bullet in my campaign to
> see the standards committee narrow it's scope to the things that only
> such a committee can do. That is:
>
> a) core language syntax and semantics
> b) core libraries which place a common interface on underlying machine
> or operating system implementations
>
> Other stuff should be considered separately.  Preferably by some other
> organization but at least by a separate committee. The current
> structure is failing to scale and the problem is growing
> (exponentially?). I'm sorry I continue to harp on this, but I'm not
> getting traction.  Note that a huge portion of standard libraries have
> their origin in other organizations - stl, boost, and others.  The
> committee has a poor track record in delivering quality libraries in a
> timely manner.
>
At risk of derailing this, at the institutions which I have previously
worked don't use boost, and don't really go outside the core of the
language.  Such a restriction would only result in a even more
significant drop in usage and interest unless the core language can be
considered *complete*.  While your argument has merit from a puristic
perspective, I contest in an applied view it would be a death knell for
the language and they retreat to C and assembly.  There are too many who
are still unwilling to learn or adapt more, and the only way to get
things to move forward for anybody is if the core language takes the
load to add functionality for those who are willing to learn it.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12