c++03 library survey

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

c++03 library survey

Boost - Dev mailing list
Hello everyone,

this is closely related to the thread about "A possible date for
dropping c++03 support" (https://groups.google.com/forum/#!topic/boost-developers-archive/i4UM-GfNu8w),
but this is NOT meant as a vote on the suggestion, and I'd ask
you to keep discussions to that thread. For the actually important
part, please scroll down to the double line (===)

For reference however, my suggestion was that c++03 support
is officially dropped somewhere around early 2020 across all
of boost. Which would mean, that from then onwards any library
author could start to unconditionally use c++11 features in
his library without prior announcement or transition period,
even if other boost libraries that currently support c++03
have a dependency on it.
(Again, if you have questions or comments about this, please
answer on the other thread)

Somewhat late, I realized I first should have asked if / how
much actual interest there is from the side of the library
maintainers in the first place, because whatever the majority
of the people on the ML thinks, it obviously won't have any
effect if the actually affected people don't have any interest
in using c++11 in the first place.

Full disclosure: I'm not a boost contributor myself (at least
nothing significant) but as a user, I have an interest in boost
libraries becoming simpler, less entangled with each other and
providing less types that are redundant in c++11 and later.
You could call that more lightweight but that is a different
topic.
 
So, to get some idea if there is any interest in this topic,
I'd ask each maintainer that is currently maintaining a c++03
compatible library to answer the following questions:

=======Please quote from here ======================================

- Which library/ies are you maintaining? (I assume this isn't some
  sort of private information - otherwise ignore the question)

- Would you like to unconditionally use c++11 features if you would
  not have to worry about this breaking boost internal users?

- Would you like to unconditionally use c++11 features if you would
  not have to worry about this breaking any users?

- Would you deprecate your library completely if there were no
  boost-internal users and your current dependencies required
  c++11 (e.g. because your library has been merged into the c++11
  standard library anyway)

- Are you yourself using any boost library (in an up-to-date version)
  in a c++03, non-boost project?
 
- Do you have any Idea if the latest versions of your library is
  used by any important/significant number of c++02 projects?
  [It is only important if *you* consider those projects important
   and or the number significant]

=======Please quote till here ======================================

Note: When I'm talking about breaking users I mean breaking due to
requiring c++11 compiler, not because you completely rewrite the API
based on new c++11 idoms - that would probably better be done in a
completely new library.

Best regards and thank you for your time

Mike


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

Re: c++03 library survey

Boost - Dev mailing list
On 08/28/18 14:37, Mike Dev via Boost wrote:
>
> - Which library/ies are you maintaining? (I assume this isn't some
>    sort of private information - otherwise ignore the question)

I maintain Boost.Log, Boost.Atomic and Boost.WinAPI. I also participate
in Boost.Core, Boost.Iterator maintenance for some components.

> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking boost internal users?
>
> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking any users?

Yes and no to both points. Yes because it would obviously make my code
simpler and cleaner. No because I don't think it is as simple as that.

For example, if I'm currently using Boost.Move or boost::shared_ptr,
does this mean I have to port my code to native rvalue references and
std::shared_ptr? If no, should I require future contributions to still
rely on these components? If the answer to the latter question is no
then this makes a mess of the library code and I wouldn't want that. If
the answer is yes to the former question then this is quite a lot of
work (e.g. in case of Boost.Log) and may even need redesigning some
parts of the library.

> - Would you deprecate your library completely if there were no
>    boost-internal users and your current dependencies required
>    c++11 (e.g. because your library has been merged into the c++11
>    standard library anyway)

This mostly relates to Boost.Atomic and the answer is absolutely not.
Boost.Atomic offers extended functionality compared to std::atomic, it
is a potential playground for future extensions that may end up in the
standard library. As I understand, the same is true wrt. other Boost
libraries that were adopted by the standard.

> - Are you yourself using any boost library (in an up-to-date version)
>    in a c++03, non-boost project?

Not me myself, but I'm aware of such projects.

I have a reverse case, where I'm using Boost.Atomic in a C++17 project
and not planning to switch to std::atomic.

> - Do you have any Idea if the latest versions of your library is
>    used by any important/significant number of c++02 projects?
>    [It is only important if *you* consider those projects important
>     and or the number significant]

I don't know what projects those are, but I receive support requests
about Boost.Log regularly. Those requests often mention C++11+ constructs.

Boost.Atomic - not so much, but it is also a much lesser and more
specialized library with a counterpart in the standard library.

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

Re: c++03 library survey

Boost - Dev mailing list
On Tue, 28 Aug 2018 at 16:10, Andrey Semashev via Boost <
[hidden email]> wrote:

> ... If the answer is yes to the former question then this is quite a lot
> of
> work (e.g. in case of Boost.Log) and may even need redesigning some
> parts of the library.
>

 C++ is a major schism from C++98, this might entail re-design. You are
hitting the core point of "let's drop C++03 support", you cannot and should
not muddle on, it needs a re-think and a reset.

This mostly relates to Boost.Atomic and the answer is absolutely not.
> Boost.Atomic offers extended functionality compared to std::atomic, it
> is a potential playground for future extensions that may end up in the
> standard library.


Then the right way forward, IMO, is to create boost::atomic v2 and bring v1
back to the std. One of the problems people run into is that things are
quite similar, but not the same. v2 can then support, and continue to
support the non-std features (and be a play-ground for new features).

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
On 08/28/18 16:55, degski wrote:

> On Tue, 28 Aug 2018 at 16:10, Andrey Semashev via Boost
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     This mostly relates to Boost.Atomic and the answer is absolutely not.
>     Boost.Atomic offers extended functionality compared to std::atomic, it
>     is a potential playground for future extensions that may end up in the
>     standard library.
>
> Then the right way forward, IMO, is to create boost::atomic v2 and bring
> v1 back to the std. One of the problems people run into is that things
> are quite similar, but not the same. v2 can then support, and continue
> to support the non-std features (and be a play-ground for new features).

Why would anyone want two Boost.Atomic libraries? And what is the use of
v1, which, presumably, would be equivalent to std::atomic?

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

Re: c++03 library survey

Boost - Dev mailing list
On Tue, 28 Aug 2018 at 17:04, Andrey Semashev via Boost <
[hidden email]> wrote:

> ... would be equivalent to std::atomic?
>

For that specific reason, yes. So, when your organization then eventually
in 2030 (or so) moves to a compiler and STL that supports std::atomic,
atomic is guaranteed to work without issue, while at the same time you can
provide the play-ground you might like to have.

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
On 08/28/18 17:34, degski via Boost wrote:
> On Tue, 28 Aug 2018 at 17:04, Andrey Semashev via Boost <
> [hidden email]> wrote:
>
>> ... would be equivalent to std::atomic?
>
> For that specific reason, yes. So, when your organization then eventually
> in 2030 (or so) moves to a compiler and STL that supports std::atomic,
> atomic is guaranteed to work without issue...

You can already use the current Boost.Atomic for that, as long as you
don't use any extensions.

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/28/18 4:37 AM, Mike Dev via Boost wrote:

> =======Please quote from here ======================================
>
> - Which library/ies are you maintaining? (I assume this isn't some
>    sort of private information - otherwise ignore the question)
Boost Serialization
>
> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking boost internal users?
There is no value to these features at this point
>
> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking any users?

>
> - Would you deprecate your library completely if there were no
>    boost-internal users and your current dependencies required
>    c++11 (e.g. because your library has been merged into the c++11
>    standard library anyway)

hmmm - normally I just respond to bug reports.  If there are no users
there would be no such reports so probably nothing would happen.

>
> - Are you yourself using any boost library (in an up-to-date version)
>    in a c++03, non-boost project?

within the boost serialization library or in other projects?

In any case, I just incorporate an std header if there is one, next I
select a boost header, and finally I write it myself.

>    
> - Do you have any Idea if the latest versions of your library is
>    used by any important/significant number of c++02 projects?
>    [It is only important if *you* consider those projects important
>     and or the number significant]

I have no idea how frequently the boost serialization library is used.
I'm sort of thinking it's more than 25 times.  But I have not statistics
on this.  I would love to know this.

====

The one thing that might happen in the future is that BS depends upon
some other boost library which gets "upgraded" to C++11 so that BS is no
longer compatible with C++03.  But this seems unlikely.  Boost libraries
don't get much maintenance.  Once it works and passes all tests, no one
messes with it.  upgrading working code from C++03 to C++11 isn't going
to add any benefit, so there it's more attractive to spend one's efforts
somewhere else.

Robert Ramey

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

Re: c++03 library survey

Boost - Dev mailing list
On Tue, 28 Aug 2018 at 17:54, Robert Ramey via Boost <[hidden email]>
wrote:

> ...  upgrading working code from C++03 to C++11 isn't going
> to add any benefit, so there it's more attractive to spend one's efforts
> somewhere else.
>

You don't think that move semantics have had a significant impact on C++
then? Maybe it has not affected BS, and you seem to say there are no
benefits to be had from move semantics in BS. Is that really really true?

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
On 8/28/18 8:40 AM, degski via Boost wrote:

> On Tue, 28 Aug 2018 at 17:54, Robert Ramey via Boost <[hidden email]>
> wrote:
>
>> ...  upgrading working code from C++03 to C++11 isn't going
>> to add any benefit, so there it's more attractive to spend one's efforts
>> somewhere else.
>>
>
> You don't think that move semantics have had a significant impact on C++
> then? Maybe it has not affected BS, and you seem to say there are no
> benefits to be had from move semantics in BS. Is that really really true?
>
> degski
>

Actually, I think the the impact of move semantics on performance of
well written existing code is minimal.  On new code which uses more
types as values it's helpful.

Of course if the library were written today, it would all the new stuff.
  I don't think it would be faster (unless it were made header only) but
it would likely have have half the number of lines of code (or less).
But the years long slog to address corner cases, workarounds for
compiler bugs and standard library bugs, etc. And there would be design
changes which would also create a bunch of ripple effects. So it would
really end up as a whole re-write.

Robert Ramey

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

Re: c++03 library survey

Boost - Dev mailing list
On Tue, 28 Aug 2018 at 19:06, Robert Ramey via Boost <[hidden email]>
wrote:

> Actually, I think the the impact of move semantics on performance of
> well written existing code is minimal.  On new code which uses more
> types as values it's helpful.
>

I don't think it has anything to do with whether the code is well written,
copying a pointer f.e. is not the same as copying a whole array of data,
because that could [should be] be the difference between move assignment
and copy assignment.

Of course if the library were written today, it would all the new stuff.
>   I don't think it would be faster (unless it were made header only) but
> it would likely have have half the number of lines of code (or less).
>

Header only is of no interest, whatsoever, in terms of performance, that's
not how things work (inlining could be affected, but that's about it, I
would say)
.

> But the years long slog to address corner cases, workarounds for
> compiler bugs and standard library bugs, etc. And there would be design
> changes which would also create a bunch of ripple effects. So it would
> really end up as a whole re-write.
>

Yes, it's a major job, hence all the resentment.

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> - Which library/ies are you maintaining? (I assume this isn't some
>    sort of private information - otherwise ignore the question)

Too many ;)

Math, Multiprecision, Regex, Type_traits, Config

> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking boost internal users?

Multiprecision: Builds with 03, but already makes fairly heavy C++11
use, and C++11 or later is really required for full functionality. C++03
support requires little maintenance other than some #ifdef's for rvalue
refs etc.  Fairly heavy use of noexcept is also used, but IMO this is an
untestable abomination anyway.  Generalised constexpr in C++14 is more
useful than C++11, along with really robust SFINAE and enable_if support
(in theory this is C++11-ish, but there are many early C++11 compilers
which choke on the code, along with more recent C++03 compilers which
handle things fine).

Math: historically needs nothing that isn't in C++03.  Constexpr support
has been gradually added to parts of the library, but is easy to
macro-ise around.  Recently, some new components have been added which
are more like C++14 as they really need generalised lambdas to work
well.  The nicest feature to have would be constexpr-if, but that's C++17.

TypeTraits: All the old C++98 cruft is still there, I don't intend to
ever change it, and if someone files a bug against say VC7.1, the answer
will be "upgrade your compiler".  There are C++11,14 and 17 isms
throughout added to support newer features in new compilers. Many traits
only work correctly post C++11.  The whole thing could probably be
greatly simplified post C++11, but I don't see much gain from going
through and ripping out the old code.  For folks that want to read the
source, I try to keep the "modern"/conforming implementation first in
the file, at least in new code.

Regex: was obviously designed when C++98 was still being formulated ;) 
Rvalue refs are the only C++11 feature that's nice to have, other things
like C++17's string_view support will gradually get added in time no doubt.

>
> - Would you like to unconditionally use c++11 features if you would
>    not have to worry about this breaking any users?

Not especially, though I dare say I would just to save a few #ifdef's in
new code.

>
> - Would you deprecate your library completely if there were no
>    boost-internal users and your current dependencies required
>    c++11 (e.g. because your library has been merged into the c++11
>    standard library anyway)

No.  While regex is in the std, I believe Boost.Regex continues to offer
useful enhancements.
Type_traits is an interesting one - if people stop using it, then
deprecation might be an option.

>
> - Are you yourself using any boost library (in an up-to-date version)
>    in a c++03, non-boost project?

No.
>    
> - Do you have any Idea if the latest versions of your library is
>    used by any important/significant number of c++02 projects?
>    [It is only important if *you* consider those projects important
>     and or the number significant]

No.  Generally I get more bug reports relating to very recent C++
versions that I haven't quite caught up with yet.  Of course these are
mature libraries, so the C++03 side of things should be pretty stable.

HTH, John.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Aug 28, 2018, 14:37 Mike Dev via Boost <[hidden email]>
wrote:
<...>

> - Which library/ies are you maintaining? (I assume this isn't some
>   sort of private information - otherwise ignore the question)
>

Any, Conversion, DLL, LexicalCast, Stacktrace, TypeIndex, Variant.


- Would you like to unconditionally use c++11 features if you would
>   not have to worry about this breaking boost internal users?
>

This could be usefull for Variant  - it will make the library slightly
smaller and well maintainable. But not much better.


- Would you like to unconditionally use c++11 features if you would
>   not have to worry about this breaking any users?
>

Same as above.


- Would you deprecate your library completely if there were no
>   boost-internal users and your current dependencies required
>   c++11 (e.g. because your library has been merged into the c++11
>   standard library anyway)
>

Not for c++11.


- Are you yourself using any boost library (in an up-to-date version)
>   in a c++03, non-boost project?
>

No.


- Do you have any Idea if the latest versions of your library is
>   used by any important/significant number of c++02 projects?
>   [It is only important if *you* consider those projects important
>    and or the number significant]
>

There are plenty.

=======Please quote till here ======================================
>

Actually, I'd like to go further than you propose. There's a plenty of
request to use C++17 classes in the Boost libraries I maintain.

So my idea is to start a new fork/branch of Boost that requires C++17
compatible compiler. This will allow library developers to use modern
features, experiment with them and invent cool things.

This will allow me to drop Any and Variant. This will also allow me to
* significantly improve/rewrite LexicalCast and drop the std::locale
dependency that insanely slows down the runtime
* implemet a DLL library that uses std::filesystem::path and
std::system_error without unnecessary dependencies on Boost

For the remaining libraries I'll be able to drop Config, TypeTriats and
some other dependencies. This will improve compile times and reduce LOC to
maintain.


Best regards and thank you for your time
>
> Mike
>

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/28/18 10:21 AM, degski via Boost wrote:

> On Tue, 28 Aug 2018 at 19:06, Robert Ramey via Boost <[hidden email]>
> wrote:
>
>> Actually, I think the the impact of move semantics on performance of
>> well written existing code is minimal.  On new code which uses more
>> types as values it's helpful.
>>
>
> I don't think it has anything to do with whether the code is well written,
> copying a pointer f.e. is not the same as copying a whole array of data,
> because that could [should be] be the difference between move assignment
> and copy assignment.

right.  One who is thinking about what he's doing is not going to copy a
whole array of data if he's using C++03.  But since C++11 makes it
efficient, he may.  So compiling C++03 code with a C++11 compiler isn't
going to make a difference.

>
> Of course if the library were written today, it would all the new stuff.
>>    I don't think it would be faster (unless it were made header only) but
>> it would likely have have half the number of lines of code (or less).
>>
>
> Header only is of no interest, whatsoever, in terms of performance, that's
> not how things work (inlining could be affected, but that's about it, I
> would say)

LOL - inlining IS the essential difference with a header only library.
It would eliminate one move in the serialization libary.  And that would
double the speed.  This is why a C++11 serialization library (cereal) is
twice as fast as boost serialization and other libraries.

>> But the years long slog to address corner cases, workarounds for
>> compiler bugs and standard library bugs, etc. And there would be design
>> changes which would also create a bunch of ripple effects. So it would
>> really end up as a whole re-write.
>>
>
> Yes, it's a major job, hence all the resentment.

It's not just resentment - there's just no benefit to it.
>
> degski
>


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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 29/08/2018 01:09, Andrey Semashev wrote:
> For example, if I'm currently using Boost.Move or boost::shared_ptr,
> does this mean I have to port my code to native rvalue references and
> std::shared_ptr?

AFAIK, migrating from Boost.Move to native references is largely
invisible to external C++11 consumers, so as a maintainer you could
decide to leave the existing code (for reduced churn) or replace it (for
code simplicity), mostly at your own whim or even piecemeal.  (Having
said that, Boost.Move does provide some code-readability improvements
for people not trained to recognise non-move vs. move-only vs. move+copy
based on constructor existence -- assuming you don't mind macros.)

(Of course, it's a breaking change for C++03 consumers, but presumably
you wouldn't care about them any more at that point.)


Migrating from boost::shared_ptr to std::shared_ptr is a different
story; while the types are similar they are not identical (Boost has
more features).  Where only used in private members it's an ABI break,
but probably an insignificant one.  Where used in public members it is a
significant change that would require user code to change as well.

Which isn't to say that you shouldn't do it -- particularly if you don't
need the extra features of boost::shared_ptr -- but it may require more
thought and/or caution.

(You make this same point later yourself in regard to Boost.Atomic.)

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Aug 28, 2018 at 7:37 AM Mike Dev via Boost <[hidden email]>
wrote:

>
> - Which library/ies are you maintaining? (I assume this isn't some
>   sort of private information - otherwise ignore the question)
>

DateTime, Format, Uuid directly, and by virtue of being on the CMT
assign, concept_check, disjoint_sets, dynamic_bitset, function
interval, iostreams, logic, mpl, pool, property_map
ptr_container, rational, statechart, tokenizer.


> - Would you like to unconditionally use c++11 features if you would
>   not have to worry about this breaking boost internal users?
>
> - Would you like to unconditionally use c++11 features if you would
>   not have to worry about this breaking any users?
>
>
I think that for CMT repositories, it doesn't matter.  Nobody's really
doing any serious refactoring on those and they are all quite old.

I understand that Howard Hinnant is working on a date/time library for
C++20.
Such a library would eventually replace Boost.DateTime, but it would be so
radically
different that people would continue to use Boost.DateTime.  I do plan on
removing
the link library from DateTime at some point and make it header-only.  Also
the timezone
handling in DateTime is sub-par and cannot leverage the IANA TZ database
properly.
Neither of these things would be affected by switching to C++11.

I've heard a number of projects to make a better Boost.Format, but no
standards
action as of yet that I know of.  If something came along, people would
continue
to use Boost.Format because another solution is unlikely to be compatible
with
the format string syntax anyway.

I don't have any specific proof of this statement, but I suspect that both
DateTime
and Format would both highly benefit from C++11 and later techniques.  As
for
poor little Uuid, it's fine the way that it is.  I don't think it would
benefit significantly
from C++11.  C++03 compatible move semantics were just added recently for
example, which leverage Boost.Move and therefore should leverage C++11
when it is enabled.  In fact, making a Boost.Format v2 would be a great
project
- a lot of fun, and would learn a lot - but would require significant time
I don't have.


> - Would you deprecate your library completely if there were no
>   boost-internal users and your current dependencies required
>   c++11 (e.g. because your library has been merged into the c++11
>   standard library anyway)
>

Looking at how boost::shared_ptr was eventually replaced with
std::shared_ptr, where the two were interchangeable with the same
signatures then I use the following solution: I add a stdcxx namespace
and use namespace forwarding and aliasing to select either boost or
std for a variety of things (mostly in atomic, function/bind, and smart_ptr
areas).
This makes the project code oblivious to which implementation is being used.
Selection there depends on language level at build time as well as
environment.

I think that in the interest of reducing workload on a project, it sure
would be nice
to say "if you want boost::date_time then use 1.xx or earlier, otherwise
use C++20".
That said, there are likely so many downstream dependencies on
boost::date_time
it would be impossible to declare it would be removed in the future.  It
would cause
too much work internally in Boost let alone outside Boost.


> - Are you yourself using any boost library (in an up-to-date version)
>   in a c++03, non-boost project?
>
>
Apache Thrift uses C++03 in the C++ thrift runtime.  It's "mostly
abstracted"
based on the above (i.e. ready for C++11) and there have been pull requests
from other folks in the community, however those were never completed and
so the projects still uses C++03.


> - Do you have any Idea if the latest versions of your library is
>   used by any important/significant number of c++03 projects?
>   [It is only important if *you* consider those projects important
>    and or the number significant]
>
>
I know that boost::format and boost::uuid are used by a commercial entity
with a C++03 project with plans to move up to something newer, but those
were just plans last I knew.

- Jim

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, 29 Aug 2018 at 01:39, Robert Ramey via Boost <[hidden email]>
wrote:

> ... One who is thinking about what he's doing is not going to copy a
> whole array of data if he's using C++03.
>

No, of course not, but there also things like std::vector, with a C++11
compiler (and STL), relocating will be far more efficient for objects that
might benefit from move semantics. In my mind perfect fowarding is part and
parcel of "move semantics", this avoids many copies, many times, these are
unavoidable pre C++11.

LOL - inlining IS the essential difference with a header only library.
> It would eliminate one move in the serialization libary.  And that would
> double the speed.


 I think the compiler is smart enough to inline when required and or can
greatly benefit from lto/pgo/lctg (whatever these things are called in
different compilers. Double the speed seems like a laudable objective [hint
hint].

This is why a C++11 serialization library (cereal) is
> twice as fast as boost serialization and other libraries.
>

For 2 reasons I would say, it's not very complex and it uses C++11. The
header only though allows for easily adding custom extensions for ones' own
types.

>> But the years long slog to address corner cases, workarounds for
> >> compiler bugs and standard library bugs, etc. And there would be design
> >> changes which would also create a bunch of ripple effects. So it would
> >> really end up as a whole re-write.
> >>
> >
> > Yes, it's a major job, hence all the resentment.
>
> It's not just resentment - there's just no benefit to it.
>

The rest of the world is just fussin' around with C++11 and forward for the
fun of it then, got it, back to C++98. I've got a copy of "C++ Templates,
The Complete Guide, 2nd Edition - David Vandevoorde, Nicolai M. Josuttis,
Douglas Gregor", I would like to swap it for your 1st edition, as I don't
need mine any longer :-)

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, 28 Aug 2018 at 21:23, Antony Polukhin via Boost <
[hidden email]> wrote:

> So my idea is to start a new fork/branch of Boost that requires C++17
> compatible compiler. This will allow library developers to use modern
> features, experiment with them and invent cool things.
>

Where is the like-button? It would also make contributing to Boost a lot
more accessible (and more rewarding) to many.

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I've heard a number of projects to make a better Boost.Format, but no
> standards action as of yet that I know of.

I think fmtlib is trying to achieve standardization:
http://fmtlib.net/Text%20Formatting.html

Kind regards,

F

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/28/18 20:36, John Maddock via Boost wrote:
>
>> - Would you deprecate your library completely if there were no
>>    boost-internal users and your current dependencies required
>>    c++11 (e.g. because your library has been merged into the c++11
>>    standard library anyway)
>
> No.  While regex is in the std, I believe Boost.Regex continues to offer
> useful enhancements.

And better performance, at least when I checked last time against libstdc++.

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

Re: c++03 library survey

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/29/18 04:00, Gavin Lambert via Boost wrote:
> On 29/08/2018 01:09, Andrey Semashev wrote:
>> For example, if I'm currently using Boost.Move or boost::shared_ptr,
>> does this mean I have to port my code to native rvalue references and
>> std::shared_ptr?
>
> AFAIK, migrating from Boost.Move to native references is largely
> invisible to external C++11 consumers, so as a maintainer you could
> decide to leave the existing code (for reduced churn) or replace it (for
> code simplicity), mostly at your own whim or even piecemeal.

It is almost invisible for users, but it's not for maintainers. Like I
said, if I want to keep my code base consistent (and I do) I would have
to perform the full transition.

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