Date: Fri, 17 Oct 2025 13:01:32 +0200
Yes.
That is a particular case of NB comment ES-047
Here is a non-pointer example:
double f(double x, double y)
pre(y!=0)
pre(x/y > 0);
Or
double g(double x)
pre(x>0)
pre(std::sqrt(x) < 100.0);
The logical conjunction of preconditions might be a solution for 2
pre-conditions. But as the number of preconditions increases that solution
is increasingly bad.
Consider:
template <typename T, typename Q, typename R>
double h(T * pt, Q * pq, R * pr)
pre(pt != nullptr)
pre(pr != nullptr)
pre(pr != nullptr)
pre(*pt + *pq + *pr > 0);
versus
template <typename T, typename Q, typename R>
double h(T * pt, Q * pq, R * pr)
pre(pt != nullptr && pr != nullptr && pr != nullptr && *pt + *pq + *pr >
0);
The conjucted form is worse both from the teachability point of view and
the maintainabilit point of view. However the first option leads today to
UB.
On Fri, Oct 17, 2025 at 12:26 PM Daniela Engert via SG21 <
sg21_at_[hidden]> wrote:
>
> > Harald Achitz via SG15 <sg15_at_[hidden]> hat am 17.10.2025 12:03
> CEST geschrieben:
> > On the internet I saw someone saying
> >
> > void fun(Foo* ptr) pre (ptr!=nullpter), pre(ptr->hasData()) { ... }
> >
> > might be a problem (for the second pre) and should be written like this
> >
> > void fun(Foo* ptr) pre (ptr!=nullpter && ptr->hasData()){ ... }
>
> > is that true?
>
> It is. Otherwise you'd get UB with 'observe' contract evaluation semantics.
>
> Thanks
> Dani
>
> >
> > Thanks, Harald
> >
> >
> > On 2025-10-17 10:43, Ville Voutilainen wrote:
> > > On Fri, 17 Oct 2025 at 11:22, Harald Achitz via SG21
> > > <sg21_at_[hidden]> wrote:
> > >> A short question:
> > >>
> > >> is it true that it is not specified how often and in which order
> contracts (pre post conditions) are evaluated,
> > >> and if it is, I wonder what is means for 'as close as possible'
> > > See [basic.contract.eval]/18, [expr.call]/7, and [expr.call]/9.
> > _______________________________________________
> > SG15 mailing list
> > SG15_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2025/10/11324.php
>
That is a particular case of NB comment ES-047
Here is a non-pointer example:
double f(double x, double y)
pre(y!=0)
pre(x/y > 0);
Or
double g(double x)
pre(x>0)
pre(std::sqrt(x) < 100.0);
The logical conjunction of preconditions might be a solution for 2
pre-conditions. But as the number of preconditions increases that solution
is increasingly bad.
Consider:
template <typename T, typename Q, typename R>
double h(T * pt, Q * pq, R * pr)
pre(pt != nullptr)
pre(pr != nullptr)
pre(pr != nullptr)
pre(*pt + *pq + *pr > 0);
versus
template <typename T, typename Q, typename R>
double h(T * pt, Q * pq, R * pr)
pre(pt != nullptr && pr != nullptr && pr != nullptr && *pt + *pq + *pr >
0);
The conjucted form is worse both from the teachability point of view and
the maintainabilit point of view. However the first option leads today to
UB.
On Fri, Oct 17, 2025 at 12:26 PM Daniela Engert via SG21 <
sg21_at_[hidden]> wrote:
>
> > Harald Achitz via SG15 <sg15_at_[hidden]> hat am 17.10.2025 12:03
> CEST geschrieben:
> > On the internet I saw someone saying
> >
> > void fun(Foo* ptr) pre (ptr!=nullpter), pre(ptr->hasData()) { ... }
> >
> > might be a problem (for the second pre) and should be written like this
> >
> > void fun(Foo* ptr) pre (ptr!=nullpter && ptr->hasData()){ ... }
>
> > is that true?
>
> It is. Otherwise you'd get UB with 'observe' contract evaluation semantics.
>
> Thanks
> Dani
>
> >
> > Thanks, Harald
> >
> >
> > On 2025-10-17 10:43, Ville Voutilainen wrote:
> > > On Fri, 17 Oct 2025 at 11:22, Harald Achitz via SG21
> > > <sg21_at_[hidden]> wrote:
> > >> A short question:
> > >>
> > >> is it true that it is not specified how often and in which order
> contracts (pre post conditions) are evaluated,
> > >> and if it is, I wonder what is means for 'as close as possible'
> > > See [basic.contract.eval]/18, [expr.call]/7, and [expr.call]/9.
> > _______________________________________________
> > SG15 mailing list
> > SG15_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2025/10/11324.php
>
Received on 2025-10-17 11:02:13
