Subject: Re: [boost] Boost.Outcome review - First questions
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2017-05-24 17:28:12
> For this review, I doubt if we should worry too much about *current
> released* compiler's performance.
> If Outcome becomes popular, we can expect compiler optimisers to focus
> their attention on optimising Outcome.
Outcome only targets very recent compilers because of performance, doesn't
it? i.e. One of the reasons cited in another mail for dropping MSVC2015
(i.e. the second newest MSVC version) in favor of only supporting MSVC2017
is that the former generates suboptimal code for this Outcome
implementation. Did I misunderstand that?
i.e. If you're talking about the next major compiler version release from
this particular vendor, what motivation is there to optimize for usage of
Outcome, when they will probably already provide their own optimal
expected<T, E> implementation?
At that point, would there be a need for Outcome for those users who are
just after an expected<T, E> implementation, and are already going to
upgrade to a standard library implementation that provides a more optimal
std::expected? I would have thoguht current compiler performance is
important for that reason.
-- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Outcome-review-First-questions-tp4694405p4694567.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk