Quantcast

Cutting headers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cutting headers

Boost - Users mailing list
Hello,

How can I cut specific library from Boost, if, for example, I don't want
to place all Boost but only one library from Boost?

Is it possible?


---
This email has been checked for viruses by AVG.
http://www.avg.com

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
On 9 May 2017 at 08:44, Igor Mironchik via Boost-users <[hidden email]> wrote:
Is it possible?
 
Without specifying which library you are thinking of, no-one can answer that question other than by saying: "It depends".

degski
--
"Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend." - Novalis 1798

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list

2017-05-09 09:07, degski via Boost-users пишет:
On 9 May 2017 at 08:44, Igor Mironchik via Boost-users <[hidden email]> wrote:
Is it possible?
 
Without specifying which library you are thinking of, no-one can answer that question other than by saying: "It depends".

I asked about such approach totally. But if there is no common answer - your answer is good enough for me. Thank you.

Virus-free. www.avg.com

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
On 05/09/2017 08:21 AM, Igor Mironchik via Boost-users wrote:

>
> 2017-05-09 09:07, degski via Boost-users пишет:
>> On 9 May 2017 at 08:44, Igor Mironchik via Boost-users
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Is it possible?
>>
>>
>> Without specifying which library you are thinking of, no-one can
>> answer that question other than by saying: "It depends".
>
> I asked about such approach totally. But if there is no common answer -
> your answer is good enough for me. Thank you.
>
>

Hi Igor,

Jens Weller once came up with a dependency analyzer of boost libraries.
IIRC, one of his motivations was aligned to your request, i.e. finding
which headers/libs a given boost library depends upon. For more
information, see:

https://meetingcpp.com/index.php/br/items/releasing-boost-dependency-analyzer-1-1.html

as this post is from 2013, I am unclear what the current status of the
project is.

Best,
P
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 5/8/17 22:44, Igor Mironchik via Boost-users wrote:
> Hello,
>
> How can I cut specific library from Boost, if, for example, I don't want
> to place all Boost but only one library from Boost?
>
> Is it possible?
>
>

Hi Igor -

The generic tool that exists in Boost is bcp. You can find more
information here:
<http://www.boost.org/doc/libs/1_64_0/tools/bcp/doc/html/index.html>

michael

--
Michael Caisse
Ciere Consulting
ciere.com
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
It looks like you fear that all the boost libraries will get included in your final executable - that's not the case. Only the code that you call gets included - that's a function of C++ compiler tool chain. Including a header makes code from that library available to your own code. You can then use using declarations or using directives for scoping. Only the functions that you call get included.

On 9 May 2017 at 11:21, Igor Mironchik via Boost-users <[hidden email]> wrote:

2017-05-09 09:07, degski via Boost-users пишет:
On 9 May 2017 at 08:44, Igor Mironchik via Boost-users <[hidden email]> wrote:
Is it possible?
 
Without specifying which library you are thinking of, no-one can answer that question other than by saying: "It depends".

I asked about such approach totally. But if there is no common answer - your answer is good enough for me. Thank you.

Virus-free. www.avg.com

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Best regards,

-Asif


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list

Hi,

Thank you for your replies.


2017-05-09 10:04, Asif Lodhi пишет:
It looks like you fear that all the boost libraries will get included in your final executable - that's not the case. Only the code that you call gets included - that's a function of C++ compiler tool chain. Including a header makes code from that library available to your own code. You can then use using declarations or using directives for scoping. Only the functions that you call get included.

No, I asked about it because I possibly will put part of Boost in the repo...


On 9 May 2017 at 11:21, Igor Mironchik via Boost-users <[hidden email]> wrote:

2017-05-09 09:07, degski via Boost-users пишет:
On 9 May 2017 at 08:44, Igor Mironchik via Boost-users <[hidden email]> wrote:
Is it possible?
 
Without specifying which library you are thinking of, no-one can answer that question other than by saying: "It depends".

I asked about such approach totally. But if there is no common answer - your answer is good enough for me. Thank you.

Virus-free. www.avg.com

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Best regards,

-Asif



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
http://www.stroustrup.com/bs_faq.html#boost
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 5/8/17 10:44 PM, Igor Mironchik via Boost-users wrote:
> Hello,
>
> How can I cut specific library from Boost, if, for example, I don't want
> to place all Boost but only one library from Boost?
>
> Is it possible?
>

I do this all the time.  I just import specific headers and link to the
particular libraries.

The only issue that arises is that some boost libraries use other boost
libraries so I have to add some other headers/libraries to the
application working set.  We have tools for determining these secondary
dependencies but for some specific technical reasons they aren't
perfect.  I just work out the dependencies by hand. It's a simple one
time procedure that just consists in building the app adding missing
pieces until it builds to completion.

Robert Ramey

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
On 09/05/2017 17:14, Robert Ramey via Boost-users wrote:

> On 5/8/17 10:44 PM, Igor Mironchik via Boost-users wrote:
>> Hello,
>>
>> How can I cut specific library from Boost, if, for example, I don't want
>> to place all Boost but only one library from Boost?
>>
>> Is it possible?
>>
>
> I do this all the time.  I just import specific headers and link to the
> particular libraries.
>
> The only issue that arises is that some boost libraries use other boost
> libraries so I have to add some other headers/libraries to the
> application working set.  We have tools for determining these secondary
> dependencies but for some specific technical reasons they aren't
> perfect.  I just work out the dependencies by hand. It's a simple one
> time procedure that just consists in building the app adding missing
> pieces until it builds to completion.

A faster way could be to use https://pypi.python.org/pypi/pcpp to
partially preprocess a Boost library and all its dependent headers into
a single, self contained include file.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
On 5/9/17 10:23 AM, Niall Douglas via Boost-users wrote:

> On 09/05/2017 17:14, Robert Ramey via Boost-users wrote:
>> On 5/8/17 10:44 PM, Igor Mironchik via Boost-users wrote:
>>> Hello,
>>>
>>> How can I cut specific library from Boost, if, for example, I don't want
>>> to place all Boost but only one library from Boost?
>>>
>>> Is it possible?
>>>
>>
>> I do this all the time.  I just import specific headers and link to the
>> particular libraries.
>>
>> The only issue that arises is that some boost libraries use other boost
>> libraries so I have to add some other headers/libraries to the
>> application working set.  We have tools for determining these secondary
>> dependencies but for some specific technical reasons they aren't
>> perfect.  I just work out the dependencies by hand. It's a simple one
>> time procedure that just consists in building the app adding missing
>> pieces until it builds to completion.
>
> A faster way could be to use https://pypi.python.org/pypi/pcpp to
> partially preprocess a Boost library and all its dependent headers into
> a single, self contained include file.

Hmmm - I was pretty skeptical that this would be helpful when I read
this.  I went to the cited page and checked out.  It wasn't all that
clear what this thing does and how to use it.  I probably could figure
it out if I had time to do so though.  But I can't believe that using it
would be simpler, faster or more effective than the procedure I just
outlined above.

>
> Niall
>

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
> -----Original Message-----
> From: Boost-users [mailto:[hidden email]] On Behalf Of Paolo Bolzoni via Boost-users
> Sent: 09 May 2017 16:05
> To: [hidden email]
> Cc: Paolo Bolzoni
> Subject: Re: [Boost-users] Cutting headers
>
> Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
> 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.

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.

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.

Enjoy!

Paul


---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830




 


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
On 10 May 2017 at 11:36, Paul A. Bristow via Boost-users <[hidden email]> wrote:
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.

In my opinion, supporting things like VC7.1 in boost is actually doing the world a dis-service. The CRT's that come with VC7.1 (f.e.) have severe, known (to black-hat hackers) security issues AND ARE NOT SUPPORTED BY Microsoft.

Microsoft is clear about what is and what isn't supported. Boost should not support more than that. If one doesn't adopt this approach, the backlog (of mess from the past) will never be cleared and windows will forever be characterised as THE unsafe platform, which I think is un-warranted.

When will boost stop supporting VC7.1 (and all the other out-dated stuff, VC8 etc etc)?
 
degski
--
"Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend." - Novalis 1798

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Wed, May 10, 2017 at 10:36 AM, Paul A. Bristow via Boost-users
<[hidden email]> wrote:

>> Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
>> 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.


> 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.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

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

 

 

From: Boost-users [mailto:[hidden email]] On Behalf Of degski via Boost-users
Sent: 10 May 2017 14:55
To: [hidden email]
Cc: degski
Subject: Re: [Boost-users] Cutting headers

 

On 10 May 2017 at 11:36, Paul A. Bristow via Boost-users <[hidden email]> wrote:

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.

 

In my opinion, supporting things like VC7.1 in boost is actually doing the world a dis-service. The CRT's that come with VC7.1 (f.e.) have severe, known (to black-hat hackers) security issues AND ARE NOT SUPPORTED BY Microsoft.

Microsoft is clear about what is and what isn't supported. Boost should not support more than that. If one doesn't adopt this approach, the backlog (of mess from the past) will never be cleared and windows will forever be characterised as THE unsafe platform, which I think is un-warranted.

When will boost stop supporting VC7.1 (and all the other out-dated stuff, VC8 etc etc)?

 

Well I think that it is, slowly, by adding new libraries that say C++11, or even C++17 only.

 

Some reasons for not trying to actively strip out C++very_old handling code are

 

1       Not gratuitously mucking up those who are stuck maintaining C++98 systems but want to use the latest Boost version (surely a good idea?).  If they have security issues, *they* should fix them; current Boost will still work.

2       It isn’t good use of limited peoples time to do this.

3       There is a very big risk of collateral damage.  If it ain’t broke, don’t fix it.

 

In short, evolution, not revolution - that usually means bloodshed ;-)

 

HTH

 

Paul

 

 

---

Paul A. Bristow

Prizet Farmhouse

Kendal UK LA8 8AB

+44 (0) 1539 561830

 

 

 

 


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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
> <[hidden email]> wrote:
>
>>> Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
>>> 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.
>


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
This is ok depending on what your definition of 'equivalent' is.
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).

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



On Wed, May 10, 2017 at 8:59 PM, Edward Diener via Boost-users <[hidden email]> 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
<[hidden email]> wrote:

Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
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.



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cutting headers

Boost - Users mailing list
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
> <[hidden email] <mailto:[hidden email]>> 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
>         <[hidden email]
>         <mailto:[hidden email]>> 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.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Loading...