Re: [Boost-users] Cutting headers

Subject: Re: [Boost-users] Cutting headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-10 22:31:36

On 5/10/2017 5:54 PM, james via Boost-users wrote:
> This is ok depending on what your definition of 'equivalent' is.

In my cxxd library 'equivalent' meant that the syntax was the "same", 
but not necessarily the implementation. However the same syntax normally 
means that the same result would be expected.

> For example, if I have something like
> 
> #ifdef MY_USE_BOOST
> using UnorderedMap = boost::unordered_map<...>
> #else
> using UnorderedMap = std::unordered_map<...>
> #endif
> 
> my code will likely compile ok, but the runtime behaviour will be 
> different when
> the key is of type int, for example, due to the different hashing 
> algorithms used
> between boost (a static_cast) and MS's implementation (computes an 
> actual hash).

While the implementation may dictate that one side or the other is 
faster or uses less memory, I hardly believe that the result of using 
UnorderedMap would be different in actual usage. That is not to say you 
might prefer one or the other based on speed or size considerations.

> 
> Was there ever an attempt to standardise the default hashing algorithms?

I do not know what this means. Is there not a std::hash implementation ?

BTW, when you top post, rather than answering inline, it is very hard to 
know to what you are referring. That is why you are admonished not to 
top post on mailing lists.

> 
> 
> 
> On Wed, May 10, 2017 at 8:59 PM, Edward Diener via Boost-users 
> <boost-users_at_[hidden] <mailto:boost-users_at_[hidden]>> wrote:
> 
>     On 5/10/2017 11:14 AM, Paolo Bolzoni via Boost-users wrote:
> 
>         On Wed, May 10, 2017 at 10:36 AM, Paul A. Bristow via Boost-users
>         <boost-users_at_[hidden]
>         <mailto:boost-users_at_[hidden]>> wrote:
> 
>                 Unfortunately it is a long standing problem, even Bjarne
>                 Stroustrup mentions it.
>                 http://www.stroustrup.com/bs_faq.html#boost
>                 <http://www.stroustrup.com/bs_faq.html#boost>
> 
> 
>             The interdependence of Boost libraries isn't a 'problem' -
>             it may be an inconvenience, but is an unavoidable
>             consequence of missing
>             built-in language features and Boost's invaluable working
>             for multiple platforms, targets and compilers and standard
>             versions.
> 
> 
>         I find this pattern all the time, so even if a bit out of topic
>         I have
>         to ask. Perhaps it is simply a language barrier.
>         Since when knowing where a problem come from makes it less a
>         problem?
>         You essentially are saying: "Yes, that's the situation. Here why. So
>         it's not a problem."
>         The problem IS there, if it is unavoidable, or incredibly
>         difficult to
>         solve, or "solving it" means to "replace it with bigger problems",
>         then it is fine and we live with it. But it does not mean that it's
>         not a problem.
> 
> 
>             Work has been done to minimize unnecessary interdependence,
>             but it remains almost impossible to write any library
>             without using some
>             other libraries, as the dependency graphs show.
> 
> 
>         True enough, but some interdipendency are a bit gratuitous.
>         Doubly now
>         that the standard language gives part of boost.
> 
> 
>     I wrote a library whose purpose was to reduce the dependence on a
>     Boost library when the C++ standard equivalent library was available
>     at compile time, while reducing to a minimum any difference in the
>     code between using Boost or the C++ standard equivalent, but no one
>     was interested. So essentially dependence on other Boost libraries,
>     even when the C++ standard equivalent is available via the compiler
>     implementation, was not seen as an issue by other Boost developers.
> 
> 
> 
> 
>             There is nothing to stop users figuring out the subset of
>             essential libraries, sometimes quite small, as others have
>             commented.  The
>             downside is that keeping up-to-date may be tiresome.
> 
> 
>         "Nothing stops users" is not even an argument. The problem is
>         exactly
>         (quoting Stroustrup) that "it [is] hard to pick and choose."
>         Hard does
>         not mean impossible.
> 
>         Said that, I DO NOT mean at all to say: boost has the problem
>         that the
>         libraries are overly coupled and so do not use it.
>         Quoting again "it is usually a really dumb idea to go and reinvent a
>         wheel that boost already offers," what I mean is: it is infortunate
>         and we have to deal with it. Just like with arrays that becomes
>         pointers.