Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*

Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2016-05-22 11:36:13

Am 22.05.2016 5:15 nachm. schrieb "Klemens Morgenstern" <
klemens.morgenstern_at_[hidden]>:
>
> Am 22.05.2016 um 15:57 schrieb Rainer Deyke:
>>
>> On 22.05.2016 13:57, Klemens Morgenstern wrote:
>>>
>>> There is something you can do: compile a new version and create a dpk
>>> for your coworkers. I get the thing about the codebase, but the argument
>>> "my ubuntu doesn't ship" is just nonsensical. By that logic you could
>>> not develop on windows at all, because it does not ship a compiler as
>>> part of the OS at all.
>>
>>
>> I am actually moving in that direction.  I just haven't gotten all of
>> the cross-compilers I need to compile, because:
>>    - Compiling gcc is complicated.
>>    - Compiling gcc cross compilers is more complicated.
>>    - Various third-party scripts to compile gcc cross compilers haven't
>> worked for me, and are complicated enough that it's not obvious to me
>> where the problem is.
>>    - I have other priorities.
>> Of course, this only works if I distribute my work in binary form
>> (doable in my case, but not an option for open source developers),
>> redistribute gcc in binary form (not a serious option in my case), or
>> require that all of my users recompile gcc (*really* not an option).
>>
>> I like clang.  I also like to test my code on multiple compilers, which
>> is why I'm using clang in addition to gcc, not as a replacement.
>>
>>
> Just out of curiosity - what platform are cross-compiling for?
>
> To be clear: I don't think it makes sense to require C++14 or something
like that. I would think is is much more sensible, to keep the development
version on the current standard, even with incomplete implementations and
provided forked subsets for older standards. I.e. you have a guarantee for
some libraries to remain C++98 compliant. But keeping new libraries on
C++11 or C++98 is not very useful; that will end like the current
(none-eabi) embedded world, where the majority still uses C.
>
> I just dislike the "I cannot do anything" attitude - and if my company
would require me to write C++98, I'd quit.

It's sometimes more complicated than this. It is true however that the
landscape improves. In our case, our users are mostly not programmers by
profession. They use the software as a means to an end, mainly to do
science. Compiling any dependencies themselves is a major burden
(independent of the used build system, btw). So they use whatever is
installed on the system. Due to the lifetime of those systems we need to
support compilers and boost versions that date back around 5 years (we
require minimal C++11 support and keep increasing the requirements step by
step).
I guess my point is, the C++ community does not solely consist of hard core
programmers who know their way around eventually, but also people who just
want to get a job done without too much hassle.

>
> Also: some features like move-semantics are game changing, causing me to
write my libraries differently; not using it would cause bad design.
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost