Ion Gaztañaga wrote:

I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc.

Regardless of what we ultimately do with TypeTraits, I think that a "core type traits" module with minimal dependencies (and no base classes) would be of at least interim value to people like Ion (and myself, for that matter) who would like to use type traits in f.ex. move and smart_ptr, but without the unnecessary dependencies on MPL, Preprocessor, TypeOf and Utility. In fact, Ion may already have started this work, inside his own module. The reasonable way forward, in my opinion, is for us to create a new module for core type traits, with (say) Ion and John Maddock as maintainers, to which then the implementations (and tests) of TypeTraits will gradually migrate. TypeTraits will then use the core traits to derive the trait value, then add all of the compatibility baggage on top for people who like that sort of thing.

On Wed, Jan 7, 2015 at 8:33 AM, Ion Gaztañaga wrote:

El 07/01/2015 a las 10:49, Antony Polukhin escribió:

...

Hi all,

I've been looking through the latest changes to drop dependencies. Stuff that I saw is very frightening.

For example:

https://github.com/boostorg/move/blob/develop/include/boost/move/detail/type... . Every boost release some issues are fixed in intrinsics of TypeTraits and is_move_* is_nothrow_* traits. Copy-pasting code from TypeTraits feels like loading a gun and pointing it on own foot.

I really don't agree. I've measured the code bloat that TypeTraits and other "low-level" libraries were bringing to some libraries and it was very noticeable. I would like to depend only on TypeTraits but that's impossible, it brings MPL, Preprocessor, etc. Including boost/container/vector.hpp was bringing MB of preprocessed lines, comparing it to 200KB of preprocessed code for <vector> and several users were complaining about compilation times. Compilation times have improved with the dependency removal. I've contributed a little bit to Boost.TypeTraits and I'd like to use it, but only if we can make Boost.TypeTraits depend only on Config/Predef.

For all the type traits that are now supported by the standard library in use, it might be nice if #include brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations. --Beman

Nevin Liber wrote:

In order to do that, we need to somehow unify the following unrelated types:

std::integral_constant boost::integral_constant boost::mpl::integral_c

Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if.

I've already suggested a way to do that. Namely, integral constant types of type T and value v need to acquire a converting constructor from anything of type U for which U::value == v.

...

...

In order to do that, we need to somehow unify the following unrelated > types:

std::integral_constant boost::integral_constant boost::mpl::integral_c

Otherwise, it'll break the world, as most usages of type traits are either via tag dispatching or enable_if.

I've already suggested a way to do that. Namely, integral constant types of type T and value v need to acquire a converting constructor from anything of type U for which U::value == v.

As explained in http://lists.boost.org/Archives/boost/2014/06/214248.php

I think these suggestions put the cart before the horse - if only "modern" compilers are to be supported - and most of these techniques seem to require something reasonably modern - then most of the type_traits dependencies could be removed anyway. So.... what is the minimal compiler requirement to be? John.

I would like to add something here if I may. Those changes in dependencies between the several boost libraries can make it a lot harder to upgrade to a new release once it becomes available. I have a rule to always do that in order to avoid long term tech debt. So to have myself as an example, I usually have to patch new releases. At th every least Preprocessor, which I need to downgrade to 1.49's version because Incredibuild doesn't work properly with higher versions. Sometimes other libs because of specific problems or bugs. Now this in turn often forces me to downgrade or modify libs that are dependencies and those that are dependent. And there's the catch. It can be hard to figure out which exactly those are. If that changes so much between the releases this has to be done every time, defeating the purpose of the whole exercise. If I consider the release as an entity that I only need to plug and play (which would be the case in an ideal world) I wouldn't care much about the interdependencies among the submodules. Personally I would prefer heavy reuse among them to reduce bugs. But since above modifications are sadly regular practice for me I prefer transparent and clean dependencies. Just my 2 cents, Stephan On Wed, Jan 7, 2015 at 7:55 PM, Peter Dimov wrote:

John Maddock wrote:

So.... what is the minimal compiler requirement to be?

...

Same as today's. I don't think that any Boost-supported compiler has trouble with simple C++03 SFINAE.

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

Getting back to the issue at hand (creating a "base" library), I would like to give my humble perspective on it. I think that the root of the problem is that a lot of the fundamental libraries in Boost, like type-traits, mpl, pp, utility, etc..., all have in common the fact that they have a few extremely useful components that are used widely both in the user-base at large and by other boost libraries (or could be used by them), and often those components were the original motivators for the creation of the library, but they also all have a number of additional "fancy" features that make sense within their prime application domains (and you can't blame library devs for wanting to fancy-up their libraries) but also constitute significant additional bloat for all those people who only need the few useful components. For instance, most people probably use the MPL for its basic meta-functions, especially the boolean stuff (if_, not_, and_...) for Sfinae and type selectors, but very few people need or want to use the whole "compile-time STL" part of MPL. The type-traits library is the same. And I think that if it were possible to distil things down to some basic components, much of the cross-dependencies and code-bloat would be eliminated, and other boost libraries could rely on those components without too much concern about getting bloated by them. I seems to me that the Boost.Core library is intended to regroup those things. But the real problem with getting a good set of components to put in Boost.Core is that there is no clear picture of what people want and what people don't want. The dependency analyser cannot capture things that people (from other boost libraries) would want to use but decided not to use (by implementing their own reduced version of it) for fear of too much bloat and dependencies, and nor is it really fine-grained enough for this purpose anyways. I think there might be a need for some form of voting/review system for people to be able to declare what specific components they would like to see added to Boost.Core (that would help them avoid the dilemma of dep./bloat versus code duplication) versus what specific components / features would need to be factored out of the code (or left out of boost.core) because of it being overly bloated. This would clearly have to be more fine-grained than just on a header-by-header basis. And the boost mailing list is far from providing an adequate forum for this type of thing. Or maybe people simply need to be more proactive in raising issues on Boost.Core's github, as I know people seem to still be just warming up to that mode of discussion. Of course, from a practical standpoint, this is difficult to realize, but I just felt I should throw that idea out there. P.S.: I find that this discussion also exemplifies what I see as a big problem with Boost discussions, that is, any decision-making discussion on broader issues quickly digresses into people raising their favourite pet-peeves (like compiler support reqs, git submoduling, distribution issues, etc.) and discussing small examples at length (like integral-constant). Cheers, Mikael.

El 07/01/2015 a las 17:48, Nevin Liber wrote:

On 7 January 2015 at 09:22, Beman Dawes wrote:

...

For all the type traits that are now supported by the standard library in use, it might be nice if #include brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.

In order to do that, we need to somehow unify the following unrelated types:

std::integral_constant boost::integral_constant boost::mpl::integral_c

We could try to improve interoperability with a type that accepts anything that seems a true/false-type. Something like: namespace boost { namespace core_traits { template<bool Value> struct bool_type { template<class BoolType> bool_type (BoolType , enable_if_internal_bool_value_is_equal_to <Value>::type * = 0 ); }; } //namespace core_traits { } //namespace boost { So every custom integral_constant would be convertible to bool_type, and a very basic trait that does not derive from integral_constant: template<class T> struct is_mytrait { static const bool value = /**/; }; could be used with tag dispatching or enable_if + is_convertible. Best, Ion

Michael Caisse wrote:

This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.

Our practice has generally been to not use the std version of something if it fails our tests, although there's always the possibility that your code happens to not be covered by our test suite.

Michael Caisse wrote:

I'm not opposed to using the vendor version but I think we need to provide control so that when something breaks for the user they can move back to the Boost version.

A compiler-provided std::is_something breaking uses of boost::is_something (with the latter implemented in terms of the former) is not any different from a compiler bug breaking uses of boost::is_something (implemented independently of std::is_something). The effects and the mitigations are the same in both cases. Either way, I think that the more important effect of Beman's suggestion is not that the trait may pick up the std one's bugs, but that users of the trait will no longer be allowed to depend on Boost-specific parts of the interface that are not present in the std trait, such as an mpl::bool_ base class.

On 2015-01-07 20:33, Michael Caisse wrote:

On 01/07/2015 07:22 AM, Beman Dawes wrote:

...

For all the type traits that are now supported by the standard library in use, it might be nice if #include brought in the standard library version. So eventually the many boost libraries that use only type traits that have been standardized would have no dependencies on the actual boost implementations.

This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.

That was a bug in MSVC8. Should that affect boost forever?

I would rather see these choices be more implicit. I am not a fan of auto-selecting between the vendor version or the Boost version for any library. It creates more surprises than I like.

It would be a lot of configurations if you want to select each feature individually. Don't know if anyone really want to do that instead of waiting for a bug workaround in the next boost release. Bo Persson

Daniel James wrote:

FWIW I'm fine with moving hash_fwd.hpp into core, or somewhere else. Its intent was always to break the dependency on the rest of the hash implementation, and if the dependency system can't understand that, then it isn't doing its job.

Creating a dependency system that will live up to everyone's expectations is not as easy as it sounds. To take hash_fwd as an example, suppose X uses hash_fwd.hpp, and Hash uses Y. The user installs X, which has to install Hash to get hash_fwd.hpp. Since the package Hash is now installed, it is listed in index.html, the users sees it as available, and tries to make use of it. If Y was not installed along with it, use of Hash would fail, and this isn't user friendly. You can get this behavior today, if you move hash_fwd.hpp to a submodule hash/fwd, but since the installer operates on packages, and hash/fwd is in the 'hash' package, the problem I outlined above will manifest. (Even if we ignore the fact that Hash is actually in the package 'functional', so things are even more coarse-grained than that.)

Daniel James wrote:

I'm certainly not having a git submodule just for one header. They're way too expensive.

In what way are git submodules expensive? (Note: this is not an argument in favor of making a git submodule for hash_fwd.hpp. It is a genuine question that will help my evaluation of the various tradeoffs.)

Daniel James wrote:

Hash isn't the package 'functional', it's in the git submodule 'functional'.

It's also in the package 'functional' (that is, it resides in the directory libs/functional and the package script and bpm at the moment do not support finer resolution than libs/*) and in the module 'functional' (it doesn't have its own include/ directory and is therefore not recognized as a submodule by boostdep). It should just be in libs/hash. For hash_fwd, we could in principle create a repository libs/fwd that will host all forwarding headers. This could be a good place for boost/detail/container_fwd.hpp, which currently resides in Detail for lack of a better home.

Daniel James wrote:

I would like to use 'libs/functional/hash/include' but our tools don't support it. There was an attempt to reorganise mpl along those lines, but it was abandoned. If it had been successful I would have done the same.

Our tools actually do support it. The problem with mpl was caused by #includes via a macro, which were accidentally working under the old organization and broke under the new one. That said,

...

It should just be in libs/hash.

is still the right thing to do.

But it isn't. I'm not going to waste time moving things around now.

<shrug> Suit yourself.

Daniel James wrote:

Jamroot has still a special case for numeric, so that's at least one place where they don't.

C:\Projects\boost-git\boost>grep numeric Jamroot C:\Projects\boost-git\boost> This is on develop. Maybe master still has the numeric special case, I haven't checked. develop however now looks at libs/*/include and libs/*/*/include as far as I can see. chrono~stopwatches already takes advantage of this. local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost libs/*/*/include/boost ] ] ; It doesn't seem to support building a submodule: all-libraries = [ MATCH .*libs/(.*)/build/.* : [ glob libs/*/build/Jamfile.v2 ] [ glob libs/*/build/Jamfile ] ] ; but that's fixable as well and doesn't matter at the moment. With all that said, I've recently grown a substantial dislike for submodules. libs/* is the way to go, even (eventually) for numeric.

Daniel James wrote:

On 8 January 2015 at 05:27, Peter Dimov wrote:

...

It [hash] 's also in the package 'functional' (that is, it resides in the directory libs/functional and the package script and bpm at the moment do not support finer resolution than libs/*)

They probably should support a finer resolution, there are several examples of this in boost.

Tradeoffs here. Nested packages (one in functional/, the other in functional/hash/) present a slight problem for bpm in that it can't just nuke libs/functional when told to remove 'functional', as it currently does. It obviously _can_ be made smarter about it, but this would require keeping metadata about what's installed and what isn't, with the potential of said metadata going out of sync with what's actually installed, being deleted by the user, and so on. Currently, you can manually delete libs/functional instead of bpm remove -f functional, both do the same thing. This simplicity of operation has its benefits for users (it's not just for my convenience).