Making two Boost libraries interoperate

Andrzej Krzemienski

24 Apr 2019 24 Apr '19

12:39 p.m.

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided). Conceptually, such customization code does not belong to Boost.Serialization: we do not expect that Boost.Serialization provides specializations for every library that someone might ever want to serialize. It would also require the maintainer of Serialization to keep track of the implementation of Optional. However, it also does not belong to Boost.Optional: we do not expect that Boost.Optional provides customization points for every framework out there that the users may want to ever use. It would also require the maintainer of Optional to keep track of the implementation of Serialization. However, it is a natural expectation of a Boost user that if the library offers two components they should just smoothly inter-operate with one another. We could provide a small module Serialization-Optional-interop, but that would require many such components to exist and be maintained by someone. I would like to obtain some guidance on how to address such issue. The same problem must already be present between other Boost libraries. Maybe this has been already brought up, and we have a policy for solving this problem somewhere? Regards, &rzej;

Show replies by date

stefan

24 Apr 24 Apr

1:02 p.m.

On 2019-04-24 8:39 a.m., Andrzej Krzemienski via Boost wrote:

...

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided).

It seems intuitive to put such code with Boost.Optional. While you may not want to make Boost.Optional as a whole be dependent on Boost.Serialization, it might be possible to create an "extension" (technically just a header in your case) that encapsulates the additional dependency, and which can be considered logically separate from the "core" of Boost.Optional. I have similar cases where certain Boost libraries wanted Python bindings (using Boost.Python). For example, Boost.MPI has Python bindings, which are however built into a separate library. So, Boost.MPI wouldn't depend on Boost.Python, but the Boost.MPI Python bindings lib would depend on both Boost.MPI and Boost.Python. Your case is similar, only that the piece that depends on both is just a header, rather than a full (compiled) library. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Andrzej Krzemienski

3:10 p.m.

śr., 24 kwi 2019 o 15:03 stefan via Boost napisał(a):

...

On 2019-04-24 8:39 a.m., Andrzej Krzemienski via Boost wrote:

...
Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided).

It seems intuitive to put such code with Boost.Optional. While you may not want to make Boost.Optional as a whole be dependent on Boost.Serialization, it might be possible to create an "extension" (technically just a header in your case) that encapsulates the additional dependency, and which can be considered logically separate from the "core" of Boost.Optional.

I have similar cases where certain Boost libraries wanted Python bindings (using Boost.Python). For example, Boost.MPI has Python bindings, which are however built into a separate library. So, Boost.MPI wouldn't depend on Boost.Python, but the Boost.MPI Python bindings lib would depend on both Boost.MPI and Boost.Python.

Your case is similar, only that the piece that depends on both is just a header, rather than a full (compiled) library.

I understand the mechanism with a "submodule inside a module". However, I do not understand what you do not find the situation symmetrical. After all, an inverse solution could be suggested for your use case: provide a Boost.Python binding for MPL lib as a submodule of Boost.MPI. This way Boost.Python wouldn't depend on Boost.MPI, but the Boost.Python MPI bindings lib would depend on both Boost.MPI and Boost.Python. IOW, why prefer Boost.MPI to Boost.Python for hosting this "gluing" module? Regards, &rzej;

stefan

3:16 p.m.

On 2019-04-24 11:10 a.m., Andrzej Krzemienski via Boost wrote:

...

I understand the mechanism with a "submodule inside a module". However, I do not understand what you do not find the situation symmetrical. After all, an inverse solution could be suggested for your use case: provide a Boost.Python binding for MPL lib as a submodule of Boost.MPI. This way Boost.Python wouldn't depend on Boost.MPI, but the Boost.Python MPI bindings lib would depend on both Boost.MPI and Boost.Python.

That's exactly the current situation. Sorry if that wasn't clear enough from my reply.

...

IOW, why prefer Boost.MPI to Boost.Python for hosting this "gluing" module?

It isn't a "gluing" module: Boost.Python has no business in knowing anything about Boost.MPI. Conceptually, the Boost.MPI Python bindings belong to Boost.MPI, but are treated as an extension so as not to leak the added dependency on Boost.Python into Boost.MPI itself (thereby letting users who don't need Python bindings not accidentally depend on it). Likewise with Boost.Serialization. If for a project X you want a layer that adds serialization support, but you don't want X as a whole to depend on it, make it a X extension. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

3:17 p.m.

Andrzej Krzemienski wrote:

...

However, I do not understand what you do not find the situation symmetrical.

The situation is asymmetrical because there are many thousands of user-defined types, but only a handful of serialization frameworks. In principle. In practice, taking a dependency on Boost.Serialization isn't desirable because it brings in half of Boost. Ideally, one ought to have been able to provide serialization support without including anything from Serialization, but I've been singing this song for more than ten years now and nobody's listening.

Andrzej Krzemienski

3:42 p.m.

śr., 24 kwi 2019 o 17:17 Peter Dimov via Boost napisał(a):

...

Andrzej Krzemienski wrote:

...
However, I do not understand what you do not find the situation symmetrical.

The situation is asymmetrical because there are many thousands of user-defined types, but only a handful of serialization frameworks.

In principle. In practice, taking a dependency on Boost.Serialization isn't desirable because it brings in half of Boost. Ideally, one ought to have been able to provide serialization support without including anything from Serialization, but I've been singing this song for more than ten years now and nobody's listening.

Indeed, if we had that in place my concerns would be moot. Regards, &rzej;

Robert Ramey

3:47 p.m.

On 4/24/19 8:17 AM, Peter Dimov via Boost wrote:

...

Andrzej Krzemienski wrote:

...
However, I do not understand what you do not find the situation symmetrical.

The situation is asymmetrical because there are many thousands of user-defined types, but only a handful of serialization frameworks.

In principle. In practice, taking a dependency on Boost.Serialization isn't desirable because it brings in half of Boost. Ideally, one ought to have been able to provide serialization support without including anything from Serialization, but I've been singing this song for more than ten years now and nobody's listening.

I've listened. It's just that it's hard to get motivated when no one really cares/notices the problem. Recently I investigated the issue and discovered that I had considered it in the course of the original library design. This is/was the motivation for creating the library in two halves - serialization and archive. The former is meant to be included in library code and has not dependency on library code or headers itself. The later implements the algorithms that actually do the serialization. This required a certain discipline to maintain. In the course of implementation/evolution of the library, this separate was compromised due to the demands of expediency and the fact that no one else seemed to care. This is one of the very few times that anyone has articulated the issue. It would be possible to make this enhancement. And it doesn't seem to be a huge job. But I'm sure it's pretty tricky and more time consuming than one would initially think. I've maintained the library (including backward compatibility for archives written under previous versions of boost!) for 15? years without too much drama. But it's hard to get motivated as I'm involved in other stuff. It's also not clear whether anyone really cares. I have no idea whether the library is used by 10 or 10,000,000 people so it's totally unclear as to what priority something like this should have. Also once such an effort is initiated, it might be difficult to keep it from spreading to addressing other subtle design issues which would unravel the effort to limit the scope to addressing this one particular issue. The problem is not limited to the serialization library, it's just more visible there. It's exacerbated by a flawed concept of "library dependency" which is a the heart of the difficulties on making progress on boost "modularization". I've pointed this outfor many years now and nobodies listening. off topic alert. It's pretty amazing that after 15 years the library is still widely? used. It's also very, very surprising that there have been no proposals for serialization in the C++ standard library that I know of. Boost has become a victim of it's own success. It needs to evolve to address Cmake/build systems, dependencies, incentivizing/recognizing boost library/tool authors, resources for library maintenance, better documentation, more reviews for libraries and more/better library submissions. Seems like we're stuck in 2010. Robert Ramey

...

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

Joaquin M López Muñoz

3:56 p.m.

El 24/04/2019 a las 14:39, Andrzej Krzemienski via Boost escribió:

...

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided).

[...]

However, it is a natural expectation of a Boost user that if the library offers two components they should just smoothly inter-operate with one another. We could provide a small module Serialization-Optional-interop, but that would require many such components to exist and be maintained by someone.

I would like to obtain some guidance on how to address such issue. The same problem must already be present between other Boost libraries. Maybe this has been already brought up, and we have a policy for solving this problem somewhere?

Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header: https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_... So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization. Joaquín M López Muñoz

stefan

4 p.m.

On 2019-04-24 11:56 a.m., Joaquin M López Muñoz via Boost wrote:

...

Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization.

Right, this is *exactly* what I tried to propose as the right approach in my first reply. :-) Stefan -- ...ich hab' noch einen Koffer in Berlin...

Robert Ramey

4:45 p.m.

On 4/24/19 9:00 AM, stefan via Boost wrote:

...

On 2019-04-24 11:56 a.m., Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization.

Right, this is *exactly* what I tried to propose as the right approach in my first reply. :-)

Right - every library should be doing this. Likely the same applies to other libraries as well. Robert Ramey

...

Stefan

--

...ich hab' noch einen Koffer in Berlin...

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

James E. King III

5:40 p.m.

On Wed, Apr 24, 2019 at 12:50 PM Robert Ramey via Boost wrote:

...

On 4/24/19 9:00 AM, stefan via Boost wrote:

...
On 2019-04-24 11:56 a.m., Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization.

Right, this is *exactly* what I tried to propose as the right approach in my first reply. :-)

Right - every library should be doing this. Likely the same applies to other libraries as well.

For Peter Dimov's dependency inspection project(s) I think would be interesting to be able to express optional headers (perhaps in each project meta?), and for each of those optional headers we could call out their dependencies separately. Chances are these are already documented per project, but not otherwise expressed. For something like cmake it would be a question as to whether their built-in library dependency logic in FindBoost.cmake was for required, or for required and optional dependencies, but that's their call. - Jim

Robert Ramey

6:43 p.m.

On 4/24/19 10:40 AM, James E. King III via Boost wrote:

...

On Wed, Apr 24, 2019 at 12:50 PM Robert Ramey via Boost wrote:

...
On 4/24/19 9:00 AM, stefan via Boost wrote:

...
On 2019-04-24 11:56 a.m., Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

So, if I want to serialize boost::flyweight's, I need to include and link with Boost.Serialization. This, I think, makes Boost.Flyweight technically not dependent on Boost.Serialization.

Right, this is *exactly* what I tried to propose as the right approach in my first reply. :-)

Right - every library should be doing this. Likely the same applies to other libraries as well.

For Peter Dimov's dependency inspection project(s) I think would be interesting to be able to express optional headers (perhaps in each project meta?), and for each of those optional headers we could call out their dependencies separately. Chances are these are already documented per project, but not otherwise expressed.

For something like cmake it would be a question as to whether their built-in library dependency logic in FindBoost.cmake was for required, or for required and optional dependencies, but that's their call.

FWIW - I don't think there is any universal, automated method of figuring out dependencies. Ultimately these have to be crafted by hand. But a good tool and provide a good starting point and perhaps work in 90%+ situations. So I would like a tool reads a collection of one or more "top" level code modules and outputs a text file of dependent headers and source files that my project needs to include. that I can then edit that can then be fed to CMake or whatever. And BTW - this would not really be a boost thing. It should work with STD and other libraries - even those which have their own (boost or otherwise) header source dependencies. Of course to make this work on would need to be able to access all the source code which might be included. The current approach avoids this - which ultimately is why it can never work. So lets call it something which denotes this - may I modestly propose: ROFL - Ramey's Orginal Federation of Libraries. Robert Ramey Robert Ramey

...

- Jim

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

Robert Ramey

4:44 p.m.

On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...

Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this. Robert Ramey

Rene Rivera

5:54 p.m.

On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have. I.e. it's things like vcpkg, conan, cget, nix, and many more that use the "modular" level dependency view. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Robert Ramey

6:33 p.m.

On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:

...

On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have.

Right. I don't mean to suggest that it's only boosts problem. It's a problem in the assumptions that all these packages make. As more and more projects are built by composition of more and more libraries (a good thing!) It becomes apparent that the original "naive notion" breaks down. That's what we're seeing. I.e. it's things like vcpkg, conan, cget,

...

nix, and many more that use the "modular" level dependency view.

Robert Ramey

Rene Rivera

6:42 p.m.

On Wed, Apr 24, 2019 at 1:34 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:

...
On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

...
This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have.

Right. I don't mean to suggest that it's only boosts problem. It's a problem in the assumptions that all these packages make. As more and more projects are built by composition of more and more libraries (a good thing!) It becomes apparent that the original "naive notion" breaks down. That's what we're seeing.

The limit of your suggestion/desire amounts to making all source code globally available as individually addressable TUs. That limit is untenable to almost all developers. And hence the line must be drawn some place in between. The existing PDMs have draw it at the published logical boundaries. For the rather same rationale that it's easy to reason about for the end-users. And it's the end-users we are trying to satisfy. I.e. it's not a "naive notion". It's an experientially derived at end-user oriented method. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Robert Ramey

6:56 p.m.

On 4/24/19 11:42 AM, Rene Rivera via Boost wrote:

...

On Wed, Apr 24, 2019 at 1:34 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:

...
On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

...
This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have.

Right. I don't mean to suggest that it's only boosts problem. It's a problem in the assumptions that all these packages make. As more and more projects are built by composition of more and more libraries (a good thing!) It becomes apparent that the original "naive notion" breaks down. That's what we're seeing.

The limit of your suggestion/desire amounts to making all source code globally available as individually addressable TUs. Agreed That limit is untenable to almost all developers. Agreed And hence the line must be drawn some place in between. Agreed.

This is why I believe that there will never be a fully automated, correct dependency generator. At some point, someone will have to specify some of the dependencies by hand using knowledge that he has that is not available to the tool including "hidden dependencies" as well as the application(s) being built. The existing PDMs have draw it at the published logical

...

boundaries. That's the rub. Right now we draw it a the "library".

For the rather same rationale that it's easy to reason about

...

for the end-users. And it's the end-users we are trying to satisfy. I.e. it's not a "naive notion". It's an experientially derived at end-user oriented method.

Hmmmm - I'm not thinking of "naive" as a pejorative term. I've tried made the case that what is correct on a small scale breaks down at large scale and characterized that as "naive" Robert Ramey

Edward Diener

25 Apr 25 Apr

1:40 a.m.

On 4/24/2019 2:42 PM, Rene Rivera via Boost wrote:

...

On Wed, Apr 24, 2019 at 1:34 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:

...
On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...
On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

...
This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have.

Right. I don't mean to suggest that it's only boosts problem. It's a problem in the assumptions that all these packages make. As more and more projects are built by composition of more and more libraries (a good thing!) It becomes apparent that the original "naive notion" breaks down. That's what we're seeing.

The limit of your suggestion/desire amounts to making all source code globally available as individually addressable TUs. That limit is untenable to almost all developers. And hence the line must be drawn some place in between. The existing PDMs have draw it at the published logical boundaries. For the rather same rationale that it's easy to reason about for the end-users. And it's the end-users we are trying to satisfy. I.e. it's not a "naive notion". It's an experientially derived at end-user oriented method.

In theory you may be right but in practice I side with Robert Ramey. If I know that when using library X I will not be including a particular header file which creates a dependency on library A, which itself has dependencies on library B and C, then my practical view is that using library X does not depend also on libraries A, B, and C, even when some dependency report says that library X depends on libraries A, B, and C. Therefore the dependency report is not applicable in my particular case. With well-designed libraries my particular case will often be the case for many other users of libraries. Therefore while in theory you may defend dependency reports which take the modular approach, in practice that approach can easily lead to wrong conclusions. That many even well established C/C++ packages do not design themselves optimally so as to minimize dependencies depending on what header files are included by a TU, and most, if not all, package managers do not have the facility for installing packages and their dependencies based on what "components", translated to header file inclusions and possibly shared libraries, is not the fault of the end user of C++ but rather our notion of dependencies.

Mateusz Loskot

11:12 p.m.

On Thu, 25 Apr 2019 at 03:40, Edward Diener via Boost wrote:

...

On 4/24/2019 2:42 PM, Rene Rivera via Boost wrote:

...
On Wed, Apr 24, 2019 at 1:34 PM Robert Ramey via Boost wrote:

...
On 4/24/19 10:54 AM, Rene Rivera via Boost wrote:

...
On Wed, Apr 24, 2019 at 11:45 AM Robert Ramey via Boost wrote:

...
On 4/24/19 8:56 AM, Joaquin M López Muñoz via Boost wrote:

...
Not sure if this helps, but the way I did it in Boost.Flyweight is by isolating all serialization code in a separate header:

https://www.boost.org/libs/flyweight/doc/reference/flyweight.html#serialize_...

...
This does help! or it would help if our dependency tools understood this. In particular flyweight library is not dependent on the serialization libraries. Only apps which use the flyweight library AND the serialization library are dependent on the serialization library. Our notion of "dependency" obscures this.

It's only "our notion" in the sense that they mirror the notion of dependencies that users of *external* package managers, dependency managers, and users thereof have.

Right. I don't mean to suggest that it's only boosts problem. It's a problem in the assumptions that all these packages make. As more and more projects are built by composition of more and more libraries (a good thing!) It becomes apparent that the original "naive notion" breaks down. That's what we're seeing.

The limit of your suggestion/desire amounts to making all source code globally available as individually addressable TUs. That limit is untenable to almost all developers. And hence the line must be drawn some place in between. The existing PDMs have draw it at the published logical boundaries. For the rather same rationale that it's easy to reason about for the end-users. And it's the end-users we are trying to satisfy. I.e. it's not a "naive notion". It's an experientially derived at end-user oriented method.

In theory you may be right but in practice I side with Robert Ramey. If I know that when using library X I will not be including a particular header file which creates a dependency on library A, which itself has dependencies on library B and C, then my practical view is that using library X does not depend also on libraries A, B, and C, even when some dependency report says that library X depends on libraries A, B, and C. Therefore the dependency report is not applicable in my particular case.

e.g. when using just #include or together with #include then MP11 does not or does depend on MPL. I side with Robert then too. I think this (and the flyweight above) opt-in approach is something worth to consider and strive to refactor libraries accordingly. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Peter Dimov

11:21 p.m.

Mateusz Loskot wrote:

...

e.g. when using just #include or together with #include then MP11 does not or does depend on MPL.

Not quite because mp11 doesn't (physically) depend on MPL even in the second case; mp11/mpl.hpp doesn't include an MPL header.

Mateusz Loskot

11:29 p.m.

On Fri, 26 Apr 2019 at 01:21, Peter Dimov via Boost wrote:

...

Mateusz Loskot wrote:

...
e.g. when using just #include or together with #include then MP11 does not or does depend on MPL.

Not quite because mp11 doesn't (physically) depend on MPL even in the second case; mp11/mpl.hpp doesn't include an MPL header.

Right, and it does not require me to include any MPL headers. Then, my example is not good. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Robert Ramey

26 Apr 26 Apr

2:50 p.m.

On 4/25/19 4:12 PM, Mateusz Loskot via Boost wrote:

...

e.g. when using just #include or together with #include then MP11 does not or does depend on MPL.

FYI - I generally discourage the definition of "convenience headers" such as used above:

...

#include

I prefer to include just those specific headers that I'm using. Yeah - it's "inconvenient" but it gives me fine control and visibility over dependencies and helps minimize compile times. I have to say I've never had a complaint with compile times in general with C++. I think it's at least partly due to this practice and approach. It also might be due to the fact when I first learned computer programming, one passed a deck of cards across a counter and came back later to see the print out - a 12 hour turnaround! So I might have a different perspective. Robert Ramey

degski

3:03 p.m.

On Fri, 26 Apr 2019 at 14:51, Robert Ramey via Boost wrote:

...

It also might be due to the fact when I first learned computer programming, one passed a deck of cards across a counter and came back later to see the print out - a 12 hour turnaround! So I might have a different perspective.

Surely not giving you any news, but we do have SSD's now. The other day I had to/was writing ~200'000 small files to disk and it took less than a couple of seconds, reading should be faster. degski -- *Microsoft, please kill Paint3D* *Microsoft, great we are keeping Paint*

Mateusz Loskot

3:25 p.m.

On Fri, 26 Apr 2019 at 16:51, Robert Ramey via Boost wrote:

...

On 4/25/19 4:12 PM, Mateusz Loskot via Boost wrote:

...
e.g. when using just #include or together with #include then MP11 does not or does depend on MPL.

FYI - I generally discourage the definition of "convenience headers" such as used above:

...
#include

I prefer to include just those specific headers that I'm using. Yeah - it's "inconvenient" but it gives me fine control and visibility over dependencies and helps minimize compile times.

It "gives you fine control" and that is surely desired. It (often) does not work for end users who really can and do benefit from such convenience headers: - they may not care about compile times but they just want to get things done - they quickly get frustrated by trial and error to get their units compiling, and docs often run short explaining "if you want feature X include X.h" not to mention "if you want customisation A of feature X include X.h and ..." For me, as a library maintainer, convenience headers allow me to deprecate, remove, rename, move around headers as I desire while restructuring code. (I'm sure I'm speaking of obvious here.) I see the fine control as belong to category of optimisation which comes later than earlier to a typical user getting started with a library. I'm very thankful Peter provided the convenience header. If I had to fish for individual MP11 headers while switching GIL from MPL to MP11, it would have taken me much longer to complete the task (which I'd approached for at least 3 times anyway). Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2025

Age (days ago)

2027

Last active (days ago)

List overview

Download

23 comments

10 participants

participants (10)

Andrzej Krzemienski
degski
Edward Diener
James E. King III
Joaquin M López Muñoz
Mateusz Loskot
Peter Dimov
Rene Rivera
Robert Ramey
stefan