Topic: class retcode - modern return code football
Author: Matt Fioravante <fmatthew5876@gmail.com>
Date: Sun, 26 Jan 2014 22:11:46 -0800 (PST)
Raw View
------=_Part_2825_6782140.1390803106981
Content-Type: text/plain; charset=UTF-8
With modern C++ we usually use exceptions to handle errors. In same cases
exceptions are inappropriate for high performance code, especially if we
expect them to be thrown and caught often. In this case its better to stick
with old school return values.
There are some common solutions:
- Return a bool. This is easy to use and obvious when the operation
succeeded for failed. Unfortunately we cannot inform the user why the
failure occurred.
- Return some proxy object with an operator bool. This is the approach
taken by streams. It can work in some special cases where the object is not
used in other contexts that could make the operator bool confusing.
- Return an int. This is what a lot of C APIs (POSIX) and main() do.
There is only one way to successuly perform an operation so return 0 on
sucess and use non-zero values for failure. Some system APIs use -ERRNO
values for failure cases. Unfortunately checking for if(!operation()) is
somewhat unintuitive and easy to make mistakes. Nothing is faster than
comparing an int.
- Return an enum. This is similar the int situation, except now we have
named tags which are restricted statically by the type system. We can
process the error code confidently with a switch statement using -Wswitch
if we need that level of granularity.
Why not combine the best approaches? Here is one idea. First you create an
enum with all of your possible error conditions. Then you wrap it using the
following retcode class template. This template has one simple feature, an
explicit operator bool() which by default returns true when the error code
value is 0 and false otherwise.
template <typename E, E ok_value = E(0)>
class retcode {
public:
typedef E value_type;
constexpr retcode(E e) : _code(e) {}
explicit operator bool() const { return _code == ok_value; }
E code() const { return _code; }
private:
E _code = ok_value;;
};
template <typename E, E okval>
bool operator==(retcode<E, okval> l, retcode<E, okval> r) { return l.code()
== r.code(); }
bool operator==(retcode<E, okval> l, retcode<E, okval>::value_type r) {
return l.code == r; }
bool operator==(retcode<E, okval>::value_type l, retcode<E, okval> r) {
return l.code == r; }
//operator!=();
Example usage:
struct strto {
enum class err {
ok,
parse,
min_range,
max_range
};
typedef retcode<err, err::ok> rc;
};
//free function with same name as class contain err enum.
strto::rc strto(string_view s, int& value, int base);
Now you can quickly and easily test the results of functions which can
return errors:
//Just check whether or not it worked
int x;
if(!strto(s, x, 10)) {
throw exception("Failed to convert string to int!");
}
//Or for more control:
if(!(auto rc = strto(s, x, 10))) {
switch(rc) {
case strto::err::parse:
throw exception("Parsing error occured!");
case strto::err::min_range:
throw exception("Underflow occured!");
case strto::err::max_range:
throw exception("Overflow occured!");
case strto::err::ok:
}
}
On the other hand, the above would look more natural without the extra
!(..) . In that case one could just use an enum.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2825_6782140.1390803106981
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>With modern C++ we usually use exceptions to handle e=
rrors. In same cases exceptions are inappropriate for high performanc=
e code, especially if we expect them to be thrown and caught often. In this=
case its better to stick with old school return values.</div><div><br></di=
v><div>There are some common solutions:</div><div><ul><li><span style=3D"li=
ne-height: normal;">Return a bool. This is easy to use and obvious when the=
operation succeeded for failed. Unfortunately we cannot inform the user wh=
y the failure occurred.</span></li><li><span style=3D"line-height: nor=
mal;">Return some proxy object with an operator bool. This is the approach =
taken by streams. It can work in some special cases where the object is not=
used in other contexts that could make the operator bool confusing.</span>=
</li><li><span style=3D"line-height: normal;">Return an int. This is what a=
lot of C APIs (POSIX) and main() do. There is only one way to successuly p=
erform an operation so return 0 on sucess and use non-zero values for failu=
re. Some system APIs use -ERRNO values for failure cases. Unfortunately che=
cking for if(!operation()) is somewhat unintuitive and easy to make mistake=
s. Nothing is faster than comparing an int.</span></li><li><span style=3D"l=
ine-height: normal;">Return an enum. This is similar the int situation, exc=
ept now we have named tags which are restricted statically by the type syst=
em. We can process the error code confidently with a switch statement using=
-Wswitch if we need that level of granularity.</span></li></ul><div>Why no=
t combine the best approaches? Here is one idea. First you create an enum w=
ith all of your possible error conditions. Then you wrap it using the follo=
wing retcode class template. This template has one simple feature, an expli=
cit operator bool() which by default returns true when the error code value=
is 0 and false otherwise.</div></div><div><br></div><div>template <type=
name E, E ok_value =3D E(0)></div><div>class retcode {</div><div>public:=
</div><div> typedef E value_type;</div><div> constexpr ret=
code(E e) : _code(e) {}</div><div> </div><div> explicit op=
erator bool() const { return _code =3D=3D ok_value; }</div><div><br></div><=
div> E code() const { return _code; }</div><div><br></div><div>privat=
e:</div><div> E _code =3D ok_value;;<br>};</div><div><br></div><div>t=
emplate <typename E, E okval></div><div>bool operator=3D=3D(retcode&l=
t;E, okval> l, retcode<E, okval> r) { return l.code() =3D=3D =
r.code(); }<br></div><div>bool operator=3D=3D(retcode<E, okval> l,&nb=
sp;retcode<E, okval>::value_type r) { return l.code =3D=3D r; }</div>=
<div>bool operator=3D=3D(retcode<E, okval>::value_type l, retcod=
e<E, okval> r) { return l.code =3D=3D r; }<br></div><div>//operator!=
=3D();</div><div><br></div><div>Example usage:</div><div><br></div>struct s=
trto {<br><div>enum class err {<br> ok,</div><div> parse,</div>=
<div> min_range,</div><div> max_range</div><div>};</div><div>ty=
pedef retcode<err, err::ok> rc;</div><div>};</div><div><br></div><div=
><br></div><div>//free function with same name as class contain err enum.</=
div><div>strto::rc strto(string_view s, int& value, int base);</div><di=
v><br></div><div>Now you can quickly and easily test the results of functio=
ns which can return errors:</div><div><br></div><div>//Just check whether o=
r not it worked</div><div>int x;</div><div>if(!strto(s, x, 10)) {<br> =
throw exception("Failed to convert string to int!");</div><div>}</div><div=
><br></div><div>//Or for more control:</div><div>if(!(auto rc =3D strto(s, =
x, 10))) {</div><div> <span style=3D"font-size: 13px;">switch(rc=
) {</span></div><div><span style=3D"font-size: 13px;"> case strto::er=
r::parse:<br> throw exception("Parsing error occured!");</span=
></div><div><span style=3D"font-size: 13px;"> case strto::err::min_ra=
nge:</span></div><div><span style=3D"font-size: 13px;"> throw =
exception("Underflow occured!");</span></div><div><span style=3D"font-size:=
13px;"> case strto::err::max_range:</span></div><div><span style=3D"=
font-size: 13px;"> throw exception("Overflow occured!");</span=
></div><div> case strto::err::ok: </div><div> }<br>}</div=
><div><br></div><div>On the other hand, the above would look more natural w=
ithout the extra !(..) . In that case one could just use an enum.</div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2825_6782140.1390803106981--
.
Author: "Diego R." <dieram3@gmail.com>
Date: Sun, 26 Jan 2014 23:06:59 -0800 (PST)
Raw View
------=_Part_2683_26334696.1390806419970
Content-Type: text/plain; charset=UTF-8
Maybe you are looking for the support given in the header <system_error>
from the error handling library.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2683_26334696.1390806419970
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Maybe you are looking for the support given in the header <system_error> from the error handling library.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_2683_26334696.1390806419970--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 27 Jan 2014 21:54:01 +0100
Raw View
This is a multi-part message in MIME format.
--------------020601070403090408060300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 27/01/14 07:11, Matt Fioravante a =C3=A9crit :
> With modern C++ we usually use exceptions to handle errors. In same=20
> cases exceptions are inappropriate for high performance code,=20
> especially if we expect them to be thrown and caught often. In this=20
> case its better to stick with old school return values.
>
> There are some common solutions:
>
> * Return a bool. This is easy to use and obvious when the operation
> succeeded for failed. Unfortunately we cannot inform the user why
> the failure occurred.
> * Return some proxy object with an operator bool. This is the
> approach taken by streams. It can work in some special cases where
> the object is not used in other contexts that could make the
> operator bool confusing.
> * Return an int. This is what a lot of C APIs (POSIX) and main() do.
> There is only one way to successuly perform an operation so return
> 0 on sucess and use non-zero values for failure. Some system APIs
> use -ERRNO values for failure cases. Unfortunately checking for
> if(!operation()) is somewhat unintuitive and easy to make
> mistakes. Nothing is faster than comparing an int.
> * Return an enum. This is similar the int situation, except now we
> have named tags which are restricted statically by the type
> system. We can process the error code confidently with a switch
> statement using -Wswitch if we need that level of granularity.
>
> Why not combine the best approaches? Here is one idea. First you=20
> create an enum with all of your possible error conditions. Then you=20
> wrap it using the following retcode class template. This template has=20
> one simple feature, an explicit operator bool() which by default=20
> returns true when the error code value is 0 and false otherwise.
>
Have you heard about the expected proposal?
https://github.com/ptal/std-expected-proposal
https://github.com/ptal/Boost.Expected
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------020601070403090408060300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 27/01/14 07:11, Matt Fioravante a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:6def1942-88bc-4df9-9eb8-18d530ddb667@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>With modern C++ we usually use exceptions to handle errors.
In same cases exceptions are inappropriate =C2=A0for high
performance code, especially if we expect them to be thrown
and caught often. In this case its better to stick with old
school return values.</div>
<div><br>
</div>
<div>There are some common solutions:</div>
<div>
<ul>
<li><span style=3D"line-height: normal;">Return a bool. This
is easy to use and obvious when the operation succeeded
for failed. Unfortunately we cannot inform the user why
the failure=C2=A0occurred.</span></li>
<li><span style=3D"line-height: normal;">Return some proxy
object with an operator bool. This is the approach taken
by streams. It can work in some special cases where the
object is not used in other contexts that could make the
operator bool confusing.</span></li>
<li><span style=3D"line-height: normal;">Return an int. This
is what a lot of C APIs (POSIX) and main() do. There is
only one way to successuly perform an operation so
return 0 on sucess and use non-zero values for failure.
Some system APIs use -ERRNO values for failure cases.
Unfortunately checking for if(!operation()) is somewhat
unintuitive and easy to make mistakes. Nothing is faster
than comparing an int.</span></li>
<li><span style=3D"line-height: normal;">Return an enum. This
is similar the int situation, except now we have named
tags which are restricted statically by the type system.
We can process the error code confidently with a switch
statement using -Wswitch if we need that level of
granularity.</span></li>
</ul>
<div>Why not combine the best approaches? Here is one idea.
First you create an enum with all of your possible error
conditions. Then you wrap it using the following retcode
class template. This template has one simple feature, an
explicit operator bool() which by default returns true when
the error code value is 0 and false otherwise.</div>
</div>
<div><br>
</div>
</div>
</blockquote>
Have you heard about the expected proposal?<br>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/ptal/std-=
expected-proposal">https://github.com/ptal/std-expected-proposal</a><br>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/ptal/Boos=
t.Expected">https://github.com/ptal/Boost.Expected</a><br>
<br>
Best,<br>
Vicente<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------020601070403090408060300--
.
Author: Brendon Costa <brendon.j.costa@gmail.com>
Date: Tue, 28 Jan 2014 11:13:58 +1100
Raw View
--047d7bea3a4e5cf94104f0fcb34f
Content-Type: text/plain; charset=ISO-8859-1
Yes. There are many code bases that avoid the use of exceptions in C++ for
whatever reason.
I think the return bool disadvantages mentioned above can be mitigated
using a similar errno pattern as POSIX uses. In particular for POSIX you
typically return a sentinel (typically -1) and then check a thread local
errno. This pattern can work with a return bool as well giving you more
detail when required by checking a thread-local as well as a simple check.
I have worked with code before where the actual thread local error was a
type erased complex type like an exception (not what they do in POSIX where
errno is just an int) I have used this before and it places fewer
restrictions on your API and allows the error detail to store more rich
information than just an integer. This worked quite well IMO.
Also propagation of the error up the call stack was simpler as each level
only needed an error return sentinel, the actual error detail remained in
the thread local value (kind-of like an exception with manual call stack
unwinding).
Restricting the actual error to an integer has many disadvantages for
generic code which can be overcome by exceptions, but this complex errno
type idea can also overcome many disadvantages already solved by exceptions
(not all).
We also tried something like Boost.Expected or wrapping return types with
an error type but we felt the usage of this thread-local errno pattern was
simpler in many cases, particularly when passing errors from multiple
sub-modules through the one interface. I.e. It behaves very much like
exceptions with manual stack un-winding.
Usage was something like below (I am sure there are many improvements that
could be made):
bool some_func()
{
if (problem)
{
set_error(std::system_error(EFAULT, std::system_category));
return false;
}
}
....
bool some_other_func()
{
if (!some_func())
// No error handling or translation required at this level just pass
the error up the stack
return false;
return true;
}
.... some usage code ...
if (!some_other_func())
{
std::system_error* e = get_error<std::system_error>();
if (e != nullptr)
// handle a system error ... similar to a catch(std::system_error& e)
else
// handle unknown error ... similar to a catch (...)
}
The above isn't exactly what we had. The above is slightly more like an
exception allowing any type to be stored in the error. We only permitted
storing our base complex error type (similar to std::system_error in some
regards but avoided any heap allocation and had a bunch of features
irrelevant to this discussion). But it gives the general gist of how it
could be used in a more generic setting as an alternative to exceptions. It
obviously doesn't solve issues arising from avoiding using exceptions in
constructors and overloaded operators though.
On 27 January 2014 17:11, Matt Fioravante <fmatthew5876@gmail.com> wrote:
> With modern C++ we usually use exceptions to handle errors. In same cases
> exceptions are inappropriate for high performance code, especially if we
> expect them to be thrown and caught often. In this case its better to stick
> with old school return values.
>
> There are some common solutions:
>
> - Return a bool. This is easy to use and obvious when the operation
> succeeded for failed. Unfortunately we cannot inform the user why the
> failure occurred.
> - Return some proxy object with an operator bool. This is the approach
> taken by streams. It can work in some special cases where the object is not
> used in other contexts that could make the operator bool confusing.
> - Return an int. This is what a lot of C APIs (POSIX) and main() do.
> There is only one way to successuly perform an operation so return 0 on
> sucess and use non-zero values for failure. Some system APIs use -ERRNO
> values for failure cases. Unfortunately checking for if(!operation()) is
> somewhat unintuitive and easy to make mistakes. Nothing is faster than
> comparing an int.
> - Return an enum. This is similar the int situation, except now we
> have named tags which are restricted statically by the type system. We can
> process the error code confidently with a switch statement using -Wswitch
> if we need that level of granularity.
>
> Why not combine the best approaches? Here is one idea. First you create an
> enum with all of your possible error conditions. Then you wrap it using the
> following retcode class template. This template has one simple feature, an
> explicit operator bool() which by default returns true when the error code
> value is 0 and false otherwise.
>
> template <typename E, E ok_value = E(0)>
> class retcode {
> public:
> typedef E value_type;
> constexpr retcode(E e) : _code(e) {}
>
> explicit operator bool() const { return _code == ok_value; }
>
> E code() const { return _code; }
>
> private:
> E _code = ok_value;;
> };
>
> template <typename E, E okval>
> bool operator==(retcode<E, okval> l, retcode<E, okval> r) { return
> l.code() == r.code(); }
> bool operator==(retcode<E, okval> l, retcode<E, okval>::value_type r) {
> return l.code == r; }
> bool operator==(retcode<E, okval>::value_type l, retcode<E, okval> r) {
> return l.code == r; }
> //operator!=();
>
> Example usage:
>
> struct strto {
> enum class err {
> ok,
> parse,
> min_range,
> max_range
> };
> typedef retcode<err, err::ok> rc;
> };
>
>
> //free function with same name as class contain err enum.
> strto::rc strto(string_view s, int& value, int base);
>
> Now you can quickly and easily test the results of functions which can
> return errors:
>
> //Just check whether or not it worked
> int x;
> if(!strto(s, x, 10)) {
> throw exception("Failed to convert string to int!");
> }
>
> //Or for more control:
> if(!(auto rc = strto(s, x, 10))) {
> switch(rc) {
> case strto::err::parse:
> throw exception("Parsing error occured!");
> case strto::err::min_range:
> throw exception("Underflow occured!");
> case strto::err::max_range:
> throw exception("Overflow occured!");
> case strto::err::ok:
> }
> }
>
> On the other hand, the above would look more natural without the extra
> !(..) . In that case one could just use an enum.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bea3a4e5cf94104f0fcb34f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Yes. There are many code bases that avoid the use of =
exceptions in C++ for whatever reason.</div><div><br></div><div>I think the=
return bool disadvantages mentioned above can be mitigated using a similar=
errno pattern as POSIX uses. In particular for POSIX you typically return =
a sentinel (typically -1) and then check a thread local errno. This pattern=
can work with a return bool as well giving you more detail when required b=
y checking a thread-local as well as a simple check.=A0<br>
</div><div><br></div><div>I have worked with code before where the actual t=
hread local error was a type erased complex type like an exception (not wha=
t they do in POSIX where errno is just an int) I have used this before and =
it places fewer restrictions on your API and allows the error detail to sto=
re more rich information than just an integer. This worked quite well IMO.=
=A0<br>
</div><div><br></div><div>Also propagation of the error up the call stack w=
as simpler as each level only needed an error return sentinel, the actual e=
rror detail remained in the thread local value (kind-of like an exception w=
ith manual call stack unwinding).</div>
<div><br></div><div>Restricting the actual error to an integer has many dis=
advantages for generic code which can be overcome by exceptions, but this c=
omplex errno type idea can also overcome many disadvantages already solved =
by exceptions (not all). =A0</div>
<div><br></div><div>We also tried something like Boost.Expected or wrapping=
return types with an error type but we felt the usage of this thread-local=
errno pattern was simpler in many cases, particularly when passing errors =
from multiple sub-modules through the one interface. I.e. It behaves very m=
uch like exceptions with manual stack un-winding.</div>
<div><br></div><div>Usage was something like below (I am sure there are man=
y improvements that could be made):</div><div><br></div><div>bool some_func=
()</div><div>{</div><div>=A0 =A0if (problem)</div><div>=A0 =A0{</div><div>=
=A0 =A0 =A0 set_error(std::system_error(EFAULT, std::system_category));</di=
v>
<div>=A0 =A0 =A0 return false;</div><div>=A0 =A0}<br></div><div>}</div><div=
><br></div><div>...</div><div><br></div><div>bool some_other_func()</div><d=
iv>{</div><div>=A0 =A0if (!some_func())</div><div>=A0 =A0 =A0 // No error h=
andling or translation required at this level just pass the error up the st=
ack</div>
<div>=A0 =A0 =A0 return false;</div><div><br></div><div>=A0 =A0return true;=
</div><div>}</div><div><br></div><div><br></div><div>... some usage code ..=
..</div><div><br></div><div>if (!some_other_func())</div><div>{</div><div>=
=A0 =A0std::system_error* e =3D get_error<std::system_error>();</div>
<div>=A0 =A0if (e !=3D nullptr)</div><div>=A0 =A0 =A0 // handle a system er=
ror ... similar to a catch(std::system_error& e)</div><div>=A0 =A0else<=
/div><div>=A0 =A0 =A0 // handle unknown error ... similar to a catch (...)<=
/div><div>}</div><div>
<br></div><div>The above isn't exactly what we had. The above is slight=
ly more like an exception allowing any type to be stored in the error. We o=
nly permitted storing our base complex error type (similar to std::system_e=
rror in some regards but avoided any heap allocation and had a bunch of fea=
tures irrelevant to this discussion). But it gives the general gist of how =
it could be used in a more generic setting as an alternative to exceptions.=
It obviously doesn't solve issues arising from avoiding using exceptio=
ns in constructors and overloaded operators though.</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">On 27 January 2014 17:11, Matt Fioravante <span dir=
=3D"ltr"><<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fm=
atthew5876@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>With modern C++ we usu=
ally use exceptions to handle errors. In same cases exceptions are inapprop=
riate =A0for high performance code, especially if we expect them to be thro=
wn and caught often. In this case its better to stick with old school retur=
n values.</div>
<div><br></div><div>There are some common solutions:</div><div><ul><li><spa=
n style=3D"line-height:normal">Return a bool. This is easy to use and obvio=
us when the operation succeeded for failed. Unfortunately we cannot inform =
the user why the failure=A0occurred.</span></li>
<li><span style=3D"line-height:normal">Return some proxy object with an ope=
rator bool. This is the approach taken by streams. It can work in some spec=
ial cases where the object is not used in other contexts that could make th=
e operator bool confusing.</span></li>
<li><span style=3D"line-height:normal">Return an int. This is what a lot of=
C APIs (POSIX) and main() do. There is only one way to successuly perform =
an operation so return 0 on sucess and use non-zero values for failure. Som=
e system APIs use -ERRNO values for failure cases. Unfortunately checking f=
or if(!operation()) is somewhat unintuitive and easy to make mistakes. Noth=
ing is faster than comparing an int.</span></li>
<li><span style=3D"line-height:normal">Return an enum. This is similar the =
int situation, except now we have named tags which are restricted staticall=
y by the type system. We can process the error code confidently with a swit=
ch statement using -Wswitch if we need that level of granularity.</span></l=
i>
</ul><div>Why not combine the best approaches? Here is one idea. First you =
create an enum with all of your possible error conditions. Then you wrap it=
using the following retcode class template. This template has one simple f=
eature, an explicit operator bool() which by default returns true when the =
error code value is 0 and false otherwise.</div>
</div><div><br></div><div>template <typename E, E ok_value =3D E(0)><=
/div><div>class retcode {</div><div>public:</div><div>=A0 typedef E value_t=
ype;</div><div>=A0 constexpr=A0retcode(E e) : _code(e) {}</div><div>=A0=A0<=
/div><div>
=A0 explicit operator bool() const { return _code =3D=3D ok_value; }</div><=
div><br></div><div>=A0 E code() const { return _code; }</div><div><br></div=
><div>private:</div><div>=A0 E _code =3D ok_value;;<br>};</div><div><br></d=
iv><div>
template <typename E, E okval></div><div>bool operator=3D=3D(retcode&=
lt;E, okval> l,=A0retcode<E, okval> r) { return l.code() =3D=3D r.=
code(); }<br></div><div>bool operator=3D=3D(retcode<E, okval> l,=A0re=
tcode<E, okval>::value_type r) { return l.code =3D=3D r; }</div>
<div>bool operator=3D=3D(retcode<E, okval>::value_type l,=A0retcode&l=
t;E, okval> r) { return l.code =3D=3D r; }<br></div><div>//operator!=3D(=
);</div><div><br></div><div>Example usage:</div><div><br></div>struct strto=
{<br><div>
enum class err {<br>=A0 ok,</div><div>=A0 parse,</div><div>=A0 min_range,</=
div><div>=A0 max_range</div><div>};</div><div>typedef retcode<err, err::=
ok> rc;</div><div>};</div><div><br></div><div><br></div><div>//free func=
tion with same name as class contain err enum.</div>
<div>strto::rc strto(string_view s, int& value, int base);</div><div><b=
r></div><div>Now you can quickly and easily test the results of functions w=
hich can return errors:</div><div><br></div><div>//Just check whether or no=
t it worked</div>
<div>int x;</div><div>if(!strto(s, x, 10)) {<br>=A0 throw exception("F=
ailed to convert string to int!");</div><div>}</div><div><br></div><di=
v>//Or for more control:</div><div>if(!(auto rc =3D strto(s, x, 10))) {</di=
v>
<div>=A0=A0<span style=3D"font-size:13px">switch(rc) {</span></div><div><sp=
an style=3D"font-size:13px">=A0 case strto::err::parse:<br>=A0 =A0 throw ex=
ception("Parsing error occured!");</span></div><div><span style=
=3D"font-size:13px">=A0 case strto::err::min_range:</span></div>
<div><span style=3D"font-size:13px">=A0 =A0 throw exception("Underflow=
occured!");</span></div><div><span style=3D"font-size:13px">=A0 case =
strto::err::max_range:</span></div><div><span style=3D"font-size:13px">=A0 =
=A0 throw exception("Overflow occured!");</span></div>
<div>=A0 case strto::err::ok: =A0</div><div>=A0 }<br>}</div><div><br></div>=
<div>On the other hand, the above would look more natural without the extra=
!(..) . In that case one could just use an enum.</div></div><span class=3D=
"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bea3a4e5cf94104f0fcb34f--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Mon, 27 Jan 2014 17:59:03 -0800 (PST)
Raw View
------=_Part_1299_10209763.1390874343399
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Vicente,
Tried getting more info about Boost.Expected<https://github.com/ptal/Boost.=
Expected>following the links provided. Did not get far. Is there any=20
documentation/discussion on the topic? Boost list maybe?
Thanks in advance,
Vladimir.
On Tuesday, January 28, 2014 7:54:01 AM UTC+11, Vicente J. Botet Escriba=20
wrote:
>
> Le 27/01/14 07:11, Matt Fioravante a =C3=A9crit :
> =20
> With modern C++ we usually use exceptions to handle errors. In same=20
> cases exceptions are inappropriate for high performance code, especially=
=20
> if we expect them to be thrown and caught often. In this case its better =
to=20
> stick with old school return values.
>
> There are some common solutions:
> =20
> - Return a bool. This is easy to use and obvious when the operation=20
> succeeded for failed. Unfortunately we cannot inform the user why the=
=20
> failure occurred.=20
> - Return some proxy object with an operator bool. This is the approach=
=20
> taken by streams. It can work in some special cases where the object i=
s not=20
> used in other contexts that could make the operator bool confusing.=20
> - Return an int. This is what a lot of C APIs (POSIX) and main() do.=
=20
> There is only one way to successuly perform an operation so return 0 o=
n=20
> sucess and use non-zero values for failure. Some system APIs use -ERRN=
O=20
> values for failure cases. Unfortunately checking for if(!operation()) =
is=20
> somewhat unintuitive and easy to make mistakes. Nothing is faster than=
=20
> comparing an int.=20
> - Return an enum. This is similar the int situation, except now we=20
> have named tags which are restricted statically by the type system. We=
can=20
> process the error code confidently with a switch statement using -Wswi=
tch=20
> if we need that level of granularity.=20
>
> Why not combine the best approaches? Here is one idea. First you create a=
n=20
> enum with all of your possible error conditions. Then you wrap it using t=
he=20
> following retcode class template. This template has one simple feature, a=
n=20
> explicit operator bool() which by default returns true when the error cod=
e=20
> value is 0 and false otherwise.
> =20
> Have you heard about the expected proposal?
>
> https://github.com/ptal/std-expected-proposal
> https://github.com/ptal/Boost.Expected
>
> Best,
> Vicente
>
>
>
>=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1299_10209763.1390874343399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Vicente,<br><br>Tried getting more info about <a href=3D"h=
ttps://github.com/ptal/Boost.Expected" target=3D"_blank">Boost.<wbr>Expecte=
d</a> following the links provided. Did not get far. Is there any documenta=
tion/discussion on the topic? Boost list maybe?<br><br>Thanks in advance,<b=
r>Vladimir.<br>
<br>On Tuesday, January 28, 2014 7:54:01 AM UTC+11, Vicente J. Botet Es=
criba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 27/01/14 07:11, Matt Fioravante a
=C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>With modern C++ we usually use exceptions to handle errors.
In same cases exceptions are inappropriate for high
performance code, especially if we expect them to be thrown
and caught often. In this case its better to stick with old
school return values.</div>
<div><br>
</div>
<div>There are some common solutions:</div>
<div>
<ul>
<li><span style=3D"line-height:normal">Return a bool. This
is easy to use and obvious when the operation succeeded
for failed. Unfortunately we cannot inform the user why
the failure occurred.</span></li>
<li><span style=3D"line-height:normal">Return some proxy
object with an operator bool. This is the approach taken
by streams. It can work in some special cases where the
object is not used in other contexts that could make the
operator bool confusing.</span></li>
<li><span style=3D"line-height:normal">Return an int. This
is what a lot of C APIs (POSIX) and main() do. There is
only one way to successuly perform an operation so
return 0 on sucess and use non-zero values for failure.
Some system APIs use -ERRNO values for failure cases.
Unfortunately checking for if(!operation()) is somewhat
unintuitive and easy to make mistakes. Nothing is faster
than comparing an int.</span></li>
<li><span style=3D"line-height:normal">Return an enum. This
is similar the int situation, except now we have named
tags which are restricted statically by the type system.
We can process the error code confidently with a switch
statement using -Wswitch if we need that level of
granularity.</span></li>
</ul>
<div>Why not combine the best approaches? Here is one idea.
First you create an enum with all of your possible error
conditions. Then you wrap it using the following retcode
class template. This template has one simple feature, an
explicit operator bool() which by default returns true when
the error code value is 0 and false otherwise.</div>
</div>
<div><br>
</div>
</div>
</blockquote>
Have you heard about the expected proposal?<br>
<br>
<a href=3D"https://github.com/ptal/std-expected-proposal" target=3D"_bl=
ank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fgithub.com%2Fptal%2Fstd-expected-proposal\46sa\75D\46sntz\0751\46usg\75A=
FQjCNEw7cUkZfEcr3s-gBva9WoRvoXnmg';return true;" onclick=3D"this.href=3D'ht=
tps://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fptal%2Fstd-expected=
-proposal\46sa\75D\46sntz\0751\46usg\75AFQjCNEw7cUkZfEcr3s-gBva9WoRvoXnmg';=
return true;">https://github.com/ptal/std-<wbr>expected-proposal</a><br>
<a href=3D"https://github.com/ptal/Boost.Expected" target=3D"_blank" on=
mousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgith=
ub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\75AFQjCNHE2vMrSfx=
R7ysJTnZYD74LnExgtg';return true;" onclick=3D"this.href=3D'https://www.goog=
le.com/url?q\75https%3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46=
sntz\0751\46usg\75AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return true;">https:/=
/github.com/ptal/Boost.<wbr>Expected</a><br>
<br>
Best,<br>
Vicente<br>
<br>
<br>
<br>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1299_10209763.1390874343399--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 28 Jan 2014 08:19:53 +0100
Raw View
This is a multi-part message in MIME format.
--------------020904030400090109060303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 28/01/14 02:59, Vladimir Batov a =C3=A9crit :
> Vicente,
>
> Tried getting more info about Boost.Expected=20
> <https://github.com/ptal/Boost.Expected> following the links provided.=20
> Did not get far. Is there any documentation/discussion on the topic?=20
> Boost list maybe?
>
Unfortunately the documentation is not available in html/pdf form. I=20
will try to upload it this evening. You can take a look at the quickbook=20
format for Boost.Expected (not really up to date) and latex for the=20
standard proposal.
There were not too much exchanges neither in this list not on the Boost=20
ML :( I hope uploading the docs would help to start the discussion. I=20
will start a new thread as soon as the documentation is uploaded.
>
> https://github.com/ptal/std-expected-proposal
> <https://github.com/ptal/std-expected-proposal>
> https://github.com/ptal/Boost.Expected
> <https://github.com/ptal/Boost.Expected>
>
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------020904030400090109060303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 28/01/14 02:59, Vladimir Batov a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:1d1dc364-94d4-4773-b40a-e3e459d74d02@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Vicente,<br>
<br>
Tried getting more info about <a moz-do-not-send=3D"true"
href=3D"https://github.com/ptal/Boost.Expected" target=3D"_blank"=
>Boost.<wbr>Expected</a>
following the links provided. Did not get far. Is there any
documentation/discussion on the topic? Boost list maybe?<br>
<br>
</div>
</blockquote>
Unfortunately the documentation is not available in html/pdf form. I
will try to upload it this evening. You can take a look at the
quickbook format for Boost.Expected (not really up to date) and
latex for the standard proposal.<br>
<br>
There were not too much exchanges neither in this list not on the
Boost ML :( I hope uploading the docs would help to start the
discussion. I will start a new thread as soon as the documentation
is uploaded.<br>
<blockquote
cite=3D"mid:1d1dc364-94d4-4773-b40a-e3e459d74d02@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> <a
moz-do-not-send=3D"true"
href=3D"https://github.com/ptal/std-expected-proposal"
target=3D"_blank"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fgithub.com%2Fptal%2Fstd-expected-proposal\46sa\75D\46sntz\0751\=
46usg\75AFQjCNEw7cUkZfEcr3s-gBva9WoRvoXnmg';return
true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fptal%2Fstd-expected-proposal\46sa\75D\46sntz\0751\46us=
g\75AFQjCNEw7cUkZfEcr3s-gBva9WoRvoXnmg';return
true;">https://github.com/ptal/std-<wbr>expected-proposal</a>=
<br>
<a moz-do-not-send=3D"true"
href=3D"https://github.com/ptal/Boost.Expected"
target=3D"_blank"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return
true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\75https%=
3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return
true;">https://github.com/ptal/Boost.<wbr>Expected</a><br>
<br>
</div>
</blockquote>
</div>
</blockquote>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------020904030400090109060303--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 28 Jan 2014 12:47:18 +0100
Raw View
--047d7b471d26eea43a04f10662fe
Content-Type: text/plain; charset=UTF-8
On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.mail.247@gmail.com>wrote:
> Tried getting more info about Boost.Expected<https://github.com/ptal/Boost.Expected>following the links provided. Did not get far. Is there any
> documentation/discussion on the topic? Boost list maybe?
>
In case that helps:
The first time I heard about Expected it was in this presentation from
Alexandrescu, the first part (there are 3 parts), which exposes the
rational of such type:
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
I believe the Boost.Expected implementation is not exactly similar but
share the same base.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b471d26eea43a04f10662fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <span dir=3D"ltr"><<a hr=
ef=3D"mailto:vb.mail.247@gmail.com" target=3D"_blank">vb.mail.247@gmail.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Tried getting more info about <a href=3D"=
https://github.com/ptal/Boost.Expected" target=3D"_blank">Boost.<u></u>Expe=
cted</a> following the links provided. Did not get far. Is there any docume=
ntation/discussion on the topic? Boost list maybe?</div>
</blockquote></div><br>In case that helps:</div><div class=3D"gmail_extra">=
The first time I heard about Expected it was in this presentation from Alex=
andrescu, the first part (there are 3 parts), which exposes the rational of=
such type:<br>
<a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andr=
ei-Alexandrescu-Systematic-Error-Handling-in-C">http://channel9.msdn.com/Sh=
ows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handl=
ing-in-C</a><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I bel=
ieve the Boost.Expected implementation is not exactly similar but share the=
same base.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b471d26eea43a04f10662fe--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 28 Jan 2014 19:41:18 +0100
Raw View
This is a multi-part message in MIME format.
--------------070909090301030909050809
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
>
> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.mail.247@gmail.com=20
> <mailto:vb.mail.247@gmail.com>> wrote:
>
> Tried getting more info about Boost.Expected
> <https://github.com/ptal/Boost.Expected> following the links
> provided. Did not get far. Is there any documentation/discussion
> on the topic? Boost list maybe?
>
>
> In case that helps:
> The first time I heard about Expected it was in this presentation from=20
> Alexandrescu, the first part (there are 3 parts), which exposes the=20
> rational of such type:
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
>
> I believe the Boost.Expected implementation is not exactly similar but=20
> share the same base.
>
Yes, Boost.Expected started based on the presentation from Alexandrescu.=20
It has been extended and redesigned to take care of some features found=20
on the future proposals and in the Haskell Monads.
The proposal is not yet ready because we want to integrate better the=20
Monads concept.
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------070909090301030909050809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lam=
otte
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAOU91OP0VgUk+AzEB+m9UvFTYnUpfWYwQYsH0S_XcvfR6-PqFw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Tue, Jan 28, 2014 at 2:59 AM,
Vladimir Batov <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:vb.mail.247@gmail.com" target=3D"_blank">vb.=
mail.247@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div dir=3D"ltr">Tried getting more info about <a
moz-do-not-send=3D"true"
href=3D"https://github.com/ptal/Boost.Expected"
target=3D"_blank">Boost.Expected</a> following the links
provided. Did not get far. Is there any
documentation/discussion on the topic? Boost list maybe?</d=
iv>
</blockquote>
</div>
<br>
In case that helps:</div>
<div class=3D"gmail_extra">The first time I heard about Expected
it was in this presentation from Alexandrescu, the first part
(there are 3 parts), which exposes the rational of such type:<br>
<a moz-do-not-send=3D"true"
href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-=
Alexandrescu-Systematic-Error-Handling-in-C">http://channel9.msdn.com/Shows=
/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling=
-in-C</a><br>
</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">I believe the Boost.Expected
implementation is not exactly similar but share the same base.</d=
iv>
</div>
<br>
</blockquote>
Yes, Boost.Expected started based on the presentation from
Alexandrescu. It has been extended and redesigned to take care of
some features found on the future proposals and in the Haskell
Monads.<br>
<br>
The proposal is not yet ready because we want to integrate better
the Monads concept. <br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070909090301030909050809--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 29 Jan 2014 08:29:40 -0800 (PST)
Raw View
------=_Part_984_29046733.1391012980421
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Boost::Expected is similar to optional but adds the capability to provide=
=20
an exception as well.
In many cases APIs have only an error value to return. I suggest this class=
=20
(which I initially presented in a thread from_string). The advantage is=20
that you can make sure that the error situation is handled in some way. I=
=20
would like this to happen at compile time but it is beyond me to find out=
=20
how (without messing up the syntax you have to write every time you use the=
=20
feature).
class error_return {
public:
error_return() m_handled(false) {} // Ok case: No exception
error_return(exception_ptr ex) : m_handled(false), m_exception(ex) {}
~error_return() {
if (m_handled)
return;
if (m_exception)
rethrow_exception(mException);
else
throw exception("return value not checked");
}
void ignore() { m_handled =3D true; } // Use to explicitly ignore err=
ors
void rethrow() { m_handled =3D true; rethrow_exception(m_exception); }
operator bool() { m_handled =3D true; return !m_exception; } // fo=
r=20
if-type check. true (good) if m_exeption is null.
private:
bool m_handled;
exception_ptr m_exception;
};
Usage:
error_return from_string(T& dest, string_view& src) {
if (... could convert ...)
return error_return();
else
return make_exception_ptr(exception("Could not convert"));
}
// No check required
from_string(dest, "123").ignore();
// Check using if
if (from_string(dest, "123"))
... handle error;
// Throw on error
from_string(dest, "123").rethrow();
// Programming error!
from_string(dest, "123"); // throws on first call even if conversion can=
=20
be made!
This is very close to a expected<void>, but adds the destructor logic that=
=20
makes sure that the value is checked or explicitly ignored. However, as I=
=20
use operator bool() to mark off the return value as checked this system=20
would not work for expected<bool>, where there would practically exist two=
=20
operator bool() functions! This can of course be mitigated by a=20
specialization, but then the semantics will probably differ.
This said, I would really like expected to have this type of way to make=20
sure that errors are handled or explicitly ignored.
I notice now that I may have missed one use case: Propagation of error=20
return to an outer function requires that the exception_ptr can be dug out=
=20
from error_return:
exception_ptr error_return::get_exception() { m_handled =3D true; retu=
rnm_exception
; }
Den tisdagen den 28:e januari 2014 kl. 10:41:18 UTC-8 skrev Vicente J.=20
Botet Escriba:
>
> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
> =20
> =20
> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com<javas=
cript:>
> > wrote:
>
>> Tried getting more info about Boost.Expected<https://github.com/ptal/Boo=
st.Expected>following the links provided. Did not get far. Is there any=20
>> documentation/discussion on the topic? Boost list maybe?
>>
> =20
> In case that helps:
> The first time I heard about Expected it was in this presentation from=20
> Alexandrescu, the first part (there are 3 parts), which exposes the=20
> rational of such type:
>
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
> =20
> I believe the Boost.Expected implementation is not exactly similar but=
=20
> share the same base.
> =20
> Yes, Boost.Expected started based on the presentation from Alexandrescu.=
=20
> It has been extended and redesigned to take care of some features found o=
n=20
> the future proposals and in the Haskell Monads.
>
> The proposal is not yet ready because we want to integrate better the=20
> Monads concept.=20
>
> Best,
> Vicente
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_984_29046733.1391012980421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Boost::Expected is similar to optional but adds the capabi=
lity to provide an exception as well.<div><br></div><div>In many cases APIs=
have only an error value to return. I suggest this class (which I initiall=
y presented in a thread from_string). The advantage is that you can make su=
re that the error situation is handled in some way. I would like this to ha=
ppen at compile time but it is beyond me to find out how (without messing u=
p the syntax you have to write every time you use the feature).</div><div><=
br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187=
, 187, 187); background-color: rgb(250, 250, 250); word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> error_return </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> error_return</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m_handled</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">false</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// Ok case: No exc=
eption</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
error_return</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">exception_ptr ex</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> m_handled</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> m_exception</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">ex</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">~</span><span style=3D"color: #000;" class=3D"styled-by-prettify">err=
or_return</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">m_handled</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">m_exception</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; rethrow_exception</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">mException</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">throw</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> exception</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"return value not checked"</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> ignore</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> m_handled </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">true</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// Use to explicitl=
y ignore errors</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> rethrow</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> m_handled </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> rethrow_exception</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">m_exception</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">operator</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> m_handled </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">true</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">!</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">m_exception</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// for if-type check. true (good) i=
f m_exeption is null.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">private</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m_ha=
ndled</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><font color=3D"#000088"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">exception_ptr </span></font><span style=3D"color: #000;" =
class=3D"styled-by-prettify">m_exception</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Usage</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>e=
rror_return from_string</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> dest</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> string_view</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">&</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> src</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> could convert </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> error_return</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">else</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> make_exception_ptr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">exception</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"Could not convert"</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">));</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br><br></span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// No check required</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>from_string</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">dest</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"123=
"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">).</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">ignore</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Check using if</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">from_string</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">dest</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"123"</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">))</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> handle error</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Throw on error</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>from_string</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">dest</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"123"</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">).</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">rethrow</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// Programming error!</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>from_string</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">dest</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"123"</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// throws on first call =
even if conversion can be made!</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br></span></div></code></div><br>This is very clo=
se to a expected<void>, but adds the destructor logic that makes sure=
that the value is checked or explicitly ignored. However, as I use operato=
r bool() to mark off the return value as checked this system would not work=
for expected<bool>, where there would practically exist two operator=
bool() functions! This can of course be mitigated by a specialization, but=
then the semantics will probably differ.</div><div><br></div><div>This sai=
d, I would really like expected to have this type of way to make sure that =
errors are handled or explicitly ignored.</div><div><br></div><div>I notice=
now that I may have missed one use case: Propagation of error return to an=
outer function requires that the exception_ptr can be dug out from error_r=
eturn:</div><div><br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> excepti=
on_ptr error_return</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>get_exception</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> m_handled </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> m_exception</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br></div><div><br></div><div><br></div><div>Den tisdagen d=
en 28:e januari 2014 kl. 10:41:18 UTC-8 skrev Vicente J. Botet Escriba:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte
a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
<div class=3D"gmail_quote">On Tue, Jan 28, 2014 at 2:59 AM,
Vladimir Batov <span dir=3D"ltr"><<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"haeD-EO1g1kJ" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">vb.ma...@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr">Tried getting more info about <a href=3D"htt=
ps://github.com/ptal/Boost.Expected" target=3D"_blank" onmousedown=3D"this.=
href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fptal%2FBo=
ost.Expected\46sa\75D\46sntz\0751\46usg\75AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgt=
g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return true;">Boost.Expected</a> follow=
ing the links
provided. Did not get far. Is there any
documentation/discussion on the topic? Boost list maybe?</d=
iv>
</blockquote>
</div>
<br>
In case that helps:</div>
<div>The first time I heard about Expected
it was in this presentation from Alexandrescu, the first part
(there are 3 parts), which exposes the rational of such type:<br>
<a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond=
-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C" target=3D"_blank"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcha=
nnel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-and-Beyond-2012-Andrei-Alexandres=
cu-Systematic-Error-Handling-in-C\46sa\75D\46sntz\0751\46usg\75AFQjCNFtZ0CN=
lHujJCAwj62GRr5CokBhlA';return true;" onclick=3D"this.href=3D'http://www.go=
ogle.com/url?q\75http%3A%2F%2Fchannel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-=
and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C\46sa\75D=
\46sntz\0751\46usg\75AFQjCNFtZ0CNlHujJCAwj62GRr5CokBhlA';return true;">http=
://channel9.msdn.com/<wbr>Shows/Going+Deep/C-and-Beyond-<wbr>2012-Andrei-Al=
exandrescu-<wbr>Systematic-Error-Handling-in-C</a><br>
</div>
<div><br>
</div>
<div>I believe the Boost.Expected
implementation is not exactly similar but share the same base.</d=
iv>
</div>
<br>
</blockquote>
Yes, Boost.Expected started based on the presentation from
Alexandrescu. It has been extended and redesigned to take care of
some features found on the future proposals and in the Haskell
Monads.<br>
<br>
The proposal is not yet ready because we want to integrate better
the Monads concept. <br>
<br>
Best,<br>
Vicente<br>
</div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_984_29046733.1391012980421--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 29 Jan 2014 12:00:39 -0500
Raw View
On 2014-01-29 11:29, Bengt Gustafsson wrote:
> [snip]
> This is very close to a expected<void>, but adds the destructor logic that
> makes sure that the value is checked or explicitly ignored. However, as I
> use operator bool() to mark off the return value as checked this system
> would not work for expected<bool>, where there would practically exist two
> operator bool() functions! This can of course be mitigated by a
> specialization, but then the semantics will probably differ.
Use value() to get the result? (Bonus points for deriving from
std::optional except for the <void> specialization.) And consider
value_or() like ignore().
Actually I'm not entirely convinced that non-void needs to throw if not
checked, since value() will do that already, and if you're not using the
value, your code is either just silly or you are calling the function
only for its side-effects (which suggests that the function itself is
poor API).
Also, this feels like something that really ought to be handled at the
language level, like GCC's warn_unused_result, as I'd much rather get a
compile-time warning/error than a runtime exception.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 31 Jan 2014 03:02:25 -0800 (PST)
Raw View
------=_Part_1853_26375969.1391166145816
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Vicente et al,
Thanks for the info and the links. Much appreciated. The concept/idea and=
=20
A. Alexandresku presentation look quite interesting as IMO it'd be quite=20
applicable in string-to-T conversions that I myself was somewhat=20
interested/involved in. Not sure how it pans out in practice. I suspect=20
generic implementation might be difficult to achieve. Will watch the space=
=20
for more documentation/info. A website or a list that I should be=20
watching/monitoring for updates?
Thanks,
V.
On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
> =20
> =20
> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com<javas=
cript:>
> > wrote:
>
>> Tried getting more info about Boost.Expected<https://github.com/ptal/Boo=
st.Expected>following the links provided. Did not get far. Is there any=20
>> documentation/discussion on the topic? Boost list maybe?
>>
> =20
> In case that helps:
> The first time I heard about Expected it was in this presentation from=20
> Alexandrescu, the first part (there are 3 parts), which exposes the=20
> rational of such type:
>
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
> =20
> I believe the Boost.Expected implementation is not exactly similar but=
=20
> share the same base.
> =20
> Yes, Boost.Expected started based on the presentation from Alexandrescu.=
=20
> It has been extended and redesigned to take care of some features found o=
n=20
> the future proposals and in the Haskell Monads.
>
> The proposal is not yet ready because we want to integrate better the=20
> Monads concept.=20
>
> Best,
> Vicente
> =20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1853_26375969.1391166145816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Vicente et al,<br><br>Thanks for the info and the links. M=
uch appreciated. The concept/idea and A. Alexandresku presentation look qui=
te interesting as IMO it'd be quite applicable in string-to-T conversions t=
hat I myself was somewhat interested/involved in. Not sure how it pans out =
in practice. I suspect generic implementation might be difficult to achieve=
.. Will watch the space for more documentation/info. A website or a li=
st that I should be watching/monitoring for updates?<br><br>Thanks,<br>V.<b=
r><br>On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet Es=
criba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte
a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
<div class=3D"gmail_quote">On Tue, Jan 28, 2014 at 2:59 AM,
Vladimir Batov <span dir=3D"ltr"><<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"haeD-EO1g1kJ" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">vb.ma...@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr">Tried getting more info about <a href=3D"htt=
ps://github.com/ptal/Boost.Expected" target=3D"_blank" onmousedown=3D"this.=
href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fptal%2FBo=
ost.Expected\46sa\75D\46sntz\0751\46usg\75AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgt=
g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return true;">Boost.Expected</a> follow=
ing the links
provided. Did not get far. Is there any
documentation/discussion on the topic? Boost list maybe?</d=
iv>
</blockquote>
</div>
<br>
In case that helps:</div>
<div>The first time I heard about Expected
it was in this presentation from Alexandrescu, the first part
(there are 3 parts), which exposes the rational of such type:<br>
<a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond=
-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C" target=3D"_blank"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcha=
nnel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-and-Beyond-2012-Andrei-Alexandres=
cu-Systematic-Error-Handling-in-C\46sa\75D\46sntz\0751\46usg\75AFQjCNFtZ0CN=
lHujJCAwj62GRr5CokBhlA';return true;" onclick=3D"this.href=3D'http://www.go=
ogle.com/url?q\75http%3A%2F%2Fchannel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-=
and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C\46sa\75D=
\46sntz\0751\46usg\75AFQjCNFtZ0CNlHujJCAwj62GRr5CokBhlA';return true;">http=
://channel9.msdn.com/<wbr>Shows/Going+Deep/C-and-Beyond-<wbr>2012-Andrei-Al=
exandrescu-<wbr>Systematic-Error-Handling-in-C</a><br>
</div>
<div><br>
</div>
<div>I believe the Boost.Expected
implementation is not exactly similar but share the same base.</d=
iv>
</div>
<br>
</blockquote>
Yes, Boost.Expected started based on the presentation from
Alexandrescu. It has been extended and redesigned to take care of
some features found on the future proposals and in the Haskell
Monads.<br>
<br>
The proposal is not yet ready because we want to integrate better
the Monads concept. <br>
<br>
Best,<br>
Vicente<br>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1853_26375969.1391166145816--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 31 Jan 2014 14:54:06 -0800 (PST)
Raw View
------=_Part_786_12742101.1391208846259
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think it must be easy to do easy things. My first choice would still be=
=20
to have the destination as a reference parameter as you don't have to mess=
=20
with the explicit template type and match it to the variable. This=20
basically leaves my original error_return class. This allows checking the=
=20
return value with a surrounding if.
I can't see a way to actually return both the value and the possible error=
=20
code without using an extra named variable, although of course it can be=20
auto typed. Together with the explicit template parameter it builds=20
clumsiness:
int x;
if (!FromString(x, "123"))
... handle error without using error code;
or
int x;
if (!auto err =3D FromString(x, "123")) // This relies on extended=20
if-initalizer functionality being suggested!
... handle error using error code available from err which I guess isba=
sically an exception_ptr
;
vs.
int x;
auto tmp =3D FromString<int>("123");
if (tmp)
x =3D tmp.value();
else
... handle error using tmp.get_error() or something like that.
Well, in the case that you need to get at the specific error code the=20
difference in clumsiness is maybe not that great. However please note that=
=20
my destructor exception gets thrown even if the first conversion didn't=20
fail, the throw is just caused by the non-checking of the result, which the=
=20
alternative code using value() which throws if the conversion went south=20
does not provide.
As the previous speaker I'm however leaning towards wishing for a language=
=20
feature that can deliver this as a compile time error. This either requires=
=20
a very specific language feature for just this case (unlikely to happen) or=
=20
maybe we could figure out some constexpr on steroids which can feed into a=
=20
static_assert? Something like being to able to return a pair where one of=
=20
the two is constexpr and the other not. The constexpr member must of course=
=20
be evaluated at compile time and thus triggers the static_assert as needed.=
=20
I'm not fully up to speed with the newest constexpr stuff like constexpr=20
constructors, maybe this is already doable? A sketch:
template<typename T> struct static_check_ret {
T retval;
~static_check_ret() { static_assert(checked, "Return code never checked=
"
); }
operator bool () { checked =3D true; }
T value_or(const T& other) { checked =3D true; }
*mutable constexpr* bool checked =3D false; // But now this one is onl=
y=20
a little constexpr! The initialization sets it false but then it can be set=
=20
true when the COMPILER sees use of the methods that sets it true!
}
If anyone sees this as valuable (I seriously doubt that) the variable could=
=20
possibly be declared *mutable constexpr *to allow this type of compile time=
=20
magic.
The great thing would of course be that we could make sure the return code=
=20
is checked at all callsites (or ignored of course) without incurring=20
runtime overhead. The limitations of what needs to be inline for the=20
compiler to be able to do this does not look appealing though. Also of=20
course the assignments to a mutable constexpr must be to constexpr data and=
=20
not inside some non-constexpr condition. Note that of course the entire=20
operator bool() and value_or() are *not *constexpr!
Can anyone come up with additional use cases for such a construct? Is it=20
even worth contemplating? Still better than a special solution for just the=
=20
return value checking enforcement case, in my mind. It looks that it could=
=20
have some use in general in template metaprogramming.
Having written this it seems quite apparent that this is a really scary=20
little feature to standardize and for compiler vendors to implement... I=20
just post this message as someone else may find more prominent use cases=20
that could motivate the standardization and implementation effort. Another=
=20
hope I have is that someone could find a way out to implement this with=20
today's definition of constexpr (we're now in 2014 after all...), which=20
would be great.
Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir Batov:
>
> Vicente et al,
>
> Thanks for the info and the links. Much appreciated. The concept/idea and=
=20
> A. Alexandresku presentation look quite interesting as IMO it'd be quite=
=20
> applicable in string-to-T conversions that I myself was somewhat=20
> interested/involved in. Not sure how it pans out in practice. I suspect=
=20
> generic implementation might be difficult to achieve. Will watch the spac=
e=20
> for more documentation/info. A website or a list that I should be=20
> watching/monitoring for updates?
>
> Thanks,
> V.
>
> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet Escrib=
a=20
> wrote:
>>
>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
>> =20
>> =20
>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com>wrot=
e:
>>
>>> Tried getting more info about Boost.Expected<https://github.com/ptal/Bo=
ost.Expected>following the links provided. Did not get far. Is there any=20
>>> documentation/discussion on the topic? Boost list maybe?
>>>
>> =20
>> In case that helps:
>> The first time I heard about Expected it was in this presentation from=
=20
>> Alexandrescu, the first part (there are 3 parts), which exposes the=20
>> rational of such type:
>>
>> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexa=
ndrescu-Systematic-Error-Handling-in-C
>> =20
>> I believe the Boost.Expected implementation is not exactly similar but=
=20
>> share the same base.
>> =20
>> Yes, Boost.Expected started based on the presentation from Alexandrescu=
..=20
>> It has been extended and redesigned to take care of some features found =
on=20
>> the future proposals and in the Haskell Monads.
>>
>> The proposal is not yet ready because we want to integrate better the=20
>> Monads concept.=20
>>
>> Best,
>> Vicente
>> =20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_786_12742101.1391208846259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think it must be easy to do easy things. My first choice=
would still be to have the destination as a reference parameter as you don=
't have to mess with the explicit template type and match it to the variabl=
e. This basically leaves my original error_return class. This allows checki=
ng the return value with a surrounding if.<div><br></div><div>I can't see a=
way to actually return both the value and the possible error code without =
using an extra named variable, although of course it can be auto typed. Tog=
ether with the explicit template parameter it builds clumsiness:</div><div>=
<br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">FromString</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"123"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> handle error without </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> error code</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br></span></div></code></div><div>or</div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px=
solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> err </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">FromString</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">"123"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// This relies on extended if-initaliz=
er functionality being suggested!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> handle error </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> error code available </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">from</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> err which I guess </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">is</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> basically an exception_ptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250); color: rgb(0, 0, 0);"><br></span><br></div><di=
v>vs.</div><div><br></div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> tmp </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Fro=
mString</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><=
;int></span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"123"</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">tmp</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> x </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> tmp</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">else</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> handle error </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> tmp</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">get_error</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">or</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> something like that</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br></span></div></code></div><div><div><br>Well, in the case t=
hat you need to get at the specific error code the difference in clumsiness=
is maybe not that great. However please note that my destructor exception =
gets thrown even if the first conversion didn't fail, the throw is just cau=
sed by the non-checking of the result, which the alternative code using val=
ue() which throws if the conversion went south does not provide.</div><div>=
<br></div><div>As the previous speaker I'm however leaning towards wishing =
for a language feature that can deliver this as a compile time error. This =
either requires a very specific language feature for just this case (unlike=
ly to happen) or maybe we could figure out some constexpr on steroids which=
can feed into a static_assert? Something like being to able to return a pa=
ir where one of the two is constexpr and the other not. The constexpr membe=
r must of course be evaluated at compile time and thus triggers the static_=
assert as needed. I'm not fully up to speed with the newest constexpr stuff=
like constexpr constructors, maybe this is already doable? A sketch:</div>=
<div><br></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#000000"><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> static_check_ret </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> T retval</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">~</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">static_check_ret</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">static_assert</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">checked</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"Return code=
never checked"</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">checked</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">true</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> T value_or</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> other</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">checked</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">true</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><b><span style=3D"color: #008;" class=3D"styled-by-prettify">mutable=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span></b=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">checked</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">false</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">  =
;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// But no=
w this one is only a little constexpr! The initialization sets it false but=
then it can be set true when the COMPILER sees use of the methods that set=
s it true!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></fo=
nt></div></code></div>If anyone sees this as valuable (I seriously doubt th=
at) the variable could possibly be declared <i>mutable constexpr </i>to all=
ow this type of compile time magic.<br>The great thing would of course be t=
hat we could make sure the return code is checked at all callsites (or igno=
red of course) without incurring runtime overhead. The limitations of what =
needs to be inline for the compiler to be able to do this does not look app=
ealing though. Also of course the assignments to a mutable constexpr must b=
e to constexpr data and not inside some non-constexpr condition. Note that =
of course the entire operator bool() and value_or() are <i>not </i>constexp=
r!</div><div><br></div><div>Can anyone come up with additional use cases fo=
r such a construct? Is it even worth contemplating? Still better than a spe=
cial solution for just the return value checking enforcement case, in my mi=
nd. It looks that it could have some use in general in template metaprogram=
ming.</div><div><br></div><div>Having written this it seems quite apparent =
that this is a really scary little feature to standardize and for compiler =
vendors to implement... I just post this message as someone else may find m=
ore prominent use cases that could motivate the standardization and impleme=
ntation effort. Another hope I have is that someone could find a way out to=
implement this with today's definition of constexpr (we're now in 2014 aft=
er all...), which would be great.</div><div><br></div><div><br>Den fredagen=
den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir Batov:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Vicente et al,<br><br>Tha=
nks for the info and the links. Much appreciated. The concept/idea and A. A=
lexandresku presentation look quite interesting as IMO it'd be quite applic=
able in string-to-T conversions that I myself was somewhat interested/invol=
ved in. Not sure how it pans out in practice. I suspect generic implementat=
ion might be difficult to achieve. Will watch the space for more documentat=
ion/info. A website or a list that I should be watching/monitoring fo=
r updates?<br><br>Thanks,<br>V.<br><br>On Wednesday, January 29, 2014 5:41:=
18 AM UTC+11, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte
a =C3=A9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
<div class=3D"gmail_quote">On Tue, Jan 28, 2014 at 2:59 AM,
Vladimir Batov <span dir=3D"ltr"><<a>vb.ma...@gmail.com</a>&=
gt;</span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div dir=3D"ltr">Tried getting more info about <a href=3D"htt=
ps://github.com/ptal/Boost.Expected" target=3D"_blank" onmousedown=3D"this.=
href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fptal%2FBo=
ost.Expected\46sa\75D\46sntz\0751\46usg\75AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgt=
g';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75htt=
ps%3A%2F%2Fgithub.com%2Fptal%2FBoost.Expected\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHE2vMrSfxR7ysJTnZYD74LnExgtg';return true;">Boost.Expected</a> follow=
ing the links
provided. Did not get far. Is there any
documentation/discussion on the topic? Boost list maybe?</d=
iv>
</blockquote>
</div>
<br>
In case that helps:</div>
<div>The first time I heard about Expected
it was in this presentation from Alexandrescu, the first part
(there are 3 parts), which exposes the rational of such type:<br>
<a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond=
-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C" target=3D"_blank"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcha=
nnel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-and-Beyond-2012-Andrei-Alexandres=
cu-Systematic-Error-Handling-in-C\46sa\75D\46sntz\0751\46usg\75AFQjCNFtZ0CN=
lHujJCAwj62GRr5CokBhlA';return true;" onclick=3D"this.href=3D'http://www.go=
ogle.com/url?q\75http%3A%2F%2Fchannel9.msdn.com%2FShows%2FGoing%2BDeep%2FC-=
and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C\46sa\75D=
\46sntz\0751\46usg\75AFQjCNFtZ0CNlHujJCAwj62GRr5CokBhlA';return true;">http=
://channel9.msdn.com/<wbr>Shows/Going+Deep/C-and-Beyond-<wbr>2012-Andrei-Al=
exandrescu-<wbr>Systematic-Error-Handling-in-C</a><br>
</div>
<div><br>
</div>
<div>I believe the Boost.Expected
implementation is not exactly similar but share the same base.</d=
iv>
</div>
<br>
</blockquote>
Yes, Boost.Expected started based on the presentation from
Alexandrescu. It has been extended and redesigned to take care of
some features found on the future proposals and in the Haskell
Monads.<br>
<br>
The proposal is not yet ready because we want to integrate better
the Monads concept. <br>
<br>
Best,<br>
Vicente<br>
</div>
</blockquote></div></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_786_12742101.1391208846259--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 1 Feb 2014 10:09:39 +1100
Raw View
> ... the destination as a reference parameter...
My *very personal* view is that, if you want your proposal to be
seriously considered by wide C++ community and to get anywhere, you
simply have to forget the Pascal-style of passing return parameters
in. IMO it goes so much against the whole C++ philosophy and style.
OTOH I can't think of one single std. library component doing that.
Please do not get me wrong. I am not judging/criticizing your
programming style and personal preferences. Only saying that IMO that
choice will push so many people away (for practical, stylistic, etc.
reasons) even before we get into a serious discussion.
Just my 2c.
V.
On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> I think it must be easy to do easy things. My first choice would still be=
to
> have the destination as a reference parameter as you don't have to mess w=
ith
> the explicit template type and match it to the variable. This basically
> leaves my original error_return class. This allows checking the return va=
lue
> with a surrounding if.
>
> I can't see a way to actually return both the value and the possible erro=
r
> code without using an extra named variable, although of course it can be
> auto typed. Together with the explicit template parameter it builds
> clumsiness:
>
> int x;
> if (!FromString(x, "123"))
> ... handle error without using error code;
>
> or
> int x;
> if (!auto err =3D FromString(x, "123")) // This relies on extended
> if-initalizer functionality being suggested!
> ... handle error using error code available from err which I guess is
> basically an exception_ptr;
>
>
>
> vs.
>
> int x;
> auto tmp =3D FromString<int>("123");
> if (tmp)
> x =3D tmp.value();
>
> else
> ... handle error using tmp.get_error() or something like that.
>
>
> Well, in the case that you need to get at the specific error code the
> difference in clumsiness is maybe not that great. However please note tha=
t
> my destructor exception gets thrown even if the first conversion didn't
> fail, the throw is just caused by the non-checking of the result, which t=
he
> alternative code using value() which throws if the conversion went south
> does not provide.
>
> As the previous speaker I'm however leaning towards wishing for a languag=
e
> feature that can deliver this as a compile time error. This either requir=
es
> a very specific language feature for just this case (unlikely to happen) =
or
> maybe we could figure out some constexpr on steroids which can feed into =
a
> static_assert? Something like being to able to return a pair where one of
> the two is constexpr and the other not. The constexpr member must of cour=
se
> be evaluated at compile time and thus triggers the static_assert as neede=
d.
> I'm not fully up to speed with the newest constexpr stuff like constexpr
> constructors, maybe this is already doable? A sketch:
>
> template<typename T> struct static_check_ret {
> T retval;
>
> ~static_check_ret() { static_assert(checked, "Return code never
> checked"); }
> operator bool () { checked =3D true; }
> T value_or(const T& other) { checked =3D true; }
> mutable constexpr bool checked =3D false; // But now this one is onl=
y a
> little constexpr! The initialization sets it false but then it can be set
> true when the COMPILER sees use of the methods that sets it true!
> }
> If anyone sees this as valuable (I seriously doubt that) the variable cou=
ld
> possibly be declared mutable constexpr to allow this type of compile time
> magic.
> The great thing would of course be that we could make sure the return cod=
e
> is checked at all callsites (or ignored of course) without incurring runt=
ime
> overhead. The limitations of what needs to be inline for the compiler to =
be
> able to do this does not look appealing though. Also of course the
> assignments to a mutable constexpr must be to constexpr data and not insi=
de
> some non-constexpr condition. Note that of course the entire operator boo=
l()
> and value_or() are not constexpr!
>
> Can anyone come up with additional use cases for such a construct? Is it
> even worth contemplating? Still better than a special solution for just t=
he
> return value checking enforcement case, in my mind. It looks that it coul=
d
> have some use in general in template metaprogramming.
>
> Having written this it seems quite apparent that this is a really scary
> little feature to standardize and for compiler vendors to implement... I
> just post this message as someone else may find more prominent use cases
> that could motivate the standardization and implementation effort. Anothe=
r
> hope I have is that someone could find a way out to implement this with
> today's definition of constexpr (we're now in 2014 after all...), which
> would be great.
>
>
> Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir Bato=
v:
>>
>> Vicente et al,
>>
>> Thanks for the info and the links. Much appreciated. The concept/idea an=
d
>> A. Alexandresku presentation look quite interesting as IMO it'd be quite
>> applicable in string-to-T conversions that I myself was somewhat
>> interested/involved in. Not sure how it pans out in practice. I suspect
>> generic implementation might be difficult to achieve. Will watch the spa=
ce
>> for more documentation/info. A website or a list that I should be
>> watching/monitoring for updates?
>>
>> Thanks,
>> V.
>>
>> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet Escri=
ba
>> wrote:
>>>
>>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
>>>
>>>
>>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com>
>>> wrote:
>>>>
>>>> Tried getting more info about Boost.Expected following the links
>>>> provided. Did not get far. Is there any documentation/discussion on th=
e
>>>> topic? Boost list maybe?
>>>
>>>
>>> In case that helps:
>>> The first time I heard about Expected it was in this presentation from
>>> Alexandrescu, the first part (there are 3 parts), which exposes the rat=
ional
>>> of such type:
>>>
>>> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alex=
andrescu-Systematic-Error-Handling-in-C
>>>
>>> I believe the Boost.Expected implementation is not exactly similar but
>>> share the same base.
>>>
>>> Yes, Boost.Expected started based on the presentation from Alexandrescu=
..
>>> It has been extended and redesigned to take care of some features found=
on
>>> the future proposals and in the Haskell Monads.
>>>
>>> The proposal is not yet ready because we want to integrate better the
>>> Monads concept.
>>>
>>> Best,
>>> Vicente
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Fri, 31 Jan 2014 15:31:26 -0800
Raw View
--f46d0447f0ee098a7904f14c9517
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It depends. If you are using out parameters just for the sake of passing
out parameters, then sure. But there's quite a lot of documented success
for libraries that give code like:
int result;
if (foo.TryParse(result))
{
// use result
}
even in other high level languages where out parameters are discouraged
(e.g. Java / C#).
This is all about making the call site pretty / understandable / easy to
maintain. Sometimes the best way to do that is with out parameters.
Sometimes the best way is to return a tuple or some other type.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Fri, Jan 31, 2014 at 3:09 PM, Vladimir Batov <vb.mail.247@gmail.com>wrot=
e:
> > ... the destination as a reference parameter...
>
> My *very personal* view is that, if you want your proposal to be
> seriously considered by wide C++ community and to get anywhere, you
> simply have to forget the Pascal-style of passing return parameters
> in. IMO it goes so much against the whole C++ philosophy and style.
> OTOH I can't think of one single std. library component doing that.
> Please do not get me wrong. I am not judging/criticizing your
> programming style and personal preferences. Only saying that IMO that
> choice will push so many people away (for practical, stylistic, etc.
> reasons) even before we get into a serious discussion.
>
> Just my 2c.
> V.
>
>
>
> On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson
> <bengt.gustafsson@beamways.com> wrote:
> > I think it must be easy to do easy things. My first choice would still
> be to
> > have the destination as a reference parameter as you don't have to mess
> with
> > the explicit template type and match it to the variable. This basically
> > leaves my original error_return class. This allows checking the return
> value
> > with a surrounding if.
> >
> > I can't see a way to actually return both the value and the possible
> error
> > code without using an extra named variable, although of course it can b=
e
> > auto typed. Together with the explicit template parameter it builds
> > clumsiness:
> >
> > int x;
> > if (!FromString(x, "123"))
> > ... handle error without using error code;
> >
> > or
> > int x;
> > if (!auto err =3D FromString(x, "123")) // This relies on extended
> > if-initalizer functionality being suggested!
> > ... handle error using error code available from err which I guess =
is
> > basically an exception_ptr;
> >
> >
> >
> > vs.
> >
> > int x;
> > auto tmp =3D FromString<int>("123");
> > if (tmp)
> > x =3D tmp.value();
> >
> > else
> > ... handle error using tmp.get_error() or something like that.
> >
> >
> > Well, in the case that you need to get at the specific error code the
> > difference in clumsiness is maybe not that great. However please note
> that
> > my destructor exception gets thrown even if the first conversion didn't
> > fail, the throw is just caused by the non-checking of the result, which
> the
> > alternative code using value() which throws if the conversion went sout=
h
> > does not provide.
> >
> > As the previous speaker I'm however leaning towards wishing for a
> language
> > feature that can deliver this as a compile time error. This either
> requires
> > a very specific language feature for just this case (unlikely to happen=
)
> or
> > maybe we could figure out some constexpr on steroids which can feed int=
o
> a
> > static_assert? Something like being to able to return a pair where one =
of
> > the two is constexpr and the other not. The constexpr member must of
> course
> > be evaluated at compile time and thus triggers the static_assert as
> needed.
> > I'm not fully up to speed with the newest constexpr stuff like constexp=
r
> > constructors, maybe this is already doable? A sketch:
> >
> > template<typename T> struct static_check_ret {
> > T retval;
> >
> > ~static_check_ret() { static_assert(checked, "Return code never
> > checked"); }
> > operator bool () { checked =3D true; }
> > T value_or(const T& other) { checked =3D true; }
> > mutable constexpr bool checked =3D false; // But now this one is o=
nly
> a
> > little constexpr! The initialization sets it false but then it can be s=
et
> > true when the COMPILER sees use of the methods that sets it true!
> > }
> > If anyone sees this as valuable (I seriously doubt that) the variable
> could
> > possibly be declared mutable constexpr to allow this type of compile ti=
me
> > magic.
> > The great thing would of course be that we could make sure the return
> code
> > is checked at all callsites (or ignored of course) without incurring
> runtime
> > overhead. The limitations of what needs to be inline for the compiler t=
o
> be
> > able to do this does not look appealing though. Also of course the
> > assignments to a mutable constexpr must be to constexpr data and not
> inside
> > some non-constexpr condition. Note that of course the entire operator
> bool()
> > and value_or() are not constexpr!
> >
> > Can anyone come up with additional use cases for such a construct? Is i=
t
> > even worth contemplating? Still better than a special solution for just
> the
> > return value checking enforcement case, in my mind. It looks that it
> could
> > have some use in general in template metaprogramming.
> >
> > Having written this it seems quite apparent that this is a really scary
> > little feature to standardize and for compiler vendors to implement... =
I
> > just post this message as someone else may find more prominent use case=
s
> > that could motivate the standardization and implementation effort.
> Another
> > hope I have is that someone could find a way out to implement this with
> > today's definition of constexpr (we're now in 2014 after all...), which
> > would be great.
> >
> >
> > Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir
> Batov:
> >>
> >> Vicente et al,
> >>
> >> Thanks for the info and the links. Much appreciated. The concept/idea
> and
> >> A. Alexandresku presentation look quite interesting as IMO it'd be qui=
te
> >> applicable in string-to-T conversions that I myself was somewhat
> >> interested/involved in. Not sure how it pans out in practice. I suspec=
t
> >> generic implementation might be difficult to achieve. Will watch the
> space
> >> for more documentation/info. A website or a list that I should be
> >> watching/monitoring for updates?
> >>
> >> Thanks,
> >> V.
> >>
> >> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet
> Escriba
> >> wrote:
> >>>
> >>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
> >>>
> >>>
> >>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Tried getting more info about Boost.Expected following the links
> >>>> provided. Did not get far. Is there any documentation/discussion on
> the
> >>>> topic? Boost list maybe?
> >>>
> >>>
> >>> In case that helps:
> >>> The first time I heard about Expected it was in this presentation fro=
m
> >>> Alexandrescu, the first part (there are 3 parts), which exposes the
> rational
> >>> of such type:
> >>>
> >>>
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
> >>>
> >>> I believe the Boost.Expected implementation is not exactly similar bu=
t
> >>> share the same base.
> >>>
> >>> Yes, Boost.Expected started based on the presentation from
> Alexandrescu.
> >>> It has been extended and redesigned to take care of some features
> found on
> >>> the future proposals and in the Haskell Monads.
> >>>
> >>> The proposal is not yet ready because we want to integrate better the
> >>> Monads concept.
> >>>
> >>> Best,
> >>> Vicente
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to
> > std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--f46d0447f0ee098a7904f14c9517
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It depends. If you are using out parameters just for =
the sake of passing out parameters, then sure. But there's quite a lot =
of documented success for libraries that give code like:</div><div><br></di=
v>
<div>int result;</div><div>if (foo.TryParse(result))</div><div>{</div><div>=
// use result</div><div>}</div><div><br></div><div>even in other high level=
languages where out parameters are discouraged (e.g. Java / C#).</div>
<div><br></div><div>This is all about making the call site pretty / underst=
andable / easy to maintain. Sometimes the best way to do that is with out p=
arameters. Sometimes the best way is to return a tuple or some other type.<=
/div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Fri, Jan 31, 2014 at 3:09 PM, Vladimi=
r Batov <span dir=3D"ltr"><<a href=3D"mailto:vb.mail.247@gmail.com" targ=
et=3D"_blank">vb.mail.247@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
> ... the destination as a reference parameter...<br>
<br>
My *very personal* view is that, if you want your proposal to be<br>
seriously considered by wide C++ community and to get anywhere, you<br>
simply have to forget the Pascal-style of passing return parameters<br>
in. IMO it goes so much against the whole C++ philosophy and style.<br>
OTOH I can't think of one single std. library component doing that.<br>
Please do not get me wrong. I am not judging/criticizing your<br>
programming style and personal preferences. Only saying that IMO that<br>
choice will push so many people away (for practical, stylistic, etc.<br>
reasons) even before we get into a serious discussion.<br>
<br>
Just my 2c.<br>
V.<br>
<br>
<br>
<br>
On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson<br>
<<a href=3D"mailto:bengt.gustafsson@beamways.com">bengt.gustafsson@beamw=
ays.com</a>> wrote:<br>
> I think it must be easy to do easy things. My first choice would still=
be to<br>
> have the destination as a reference parameter as you don't have to=
mess with<br>
> the explicit template type and match it to the variable. This basicall=
y<br>
> leaves my original error_return class. This allows checking the return=
value<br>
> with a surrounding if.<br>
><br>
> I can't see a way to actually return both the value and the possib=
le error<br>
> code without using an extra named variable, although of course it can =
be<br>
> auto typed. Together with the explicit template parameter it builds<br=
>
> clumsiness:<br>
><br>
> int x;<br>
> if (!FromString(x, "123"))<br>
> =C2=A0 =C2=A0 ... handle error without using error code;<br>
><br>
> or<br>
> int x;<br>
> if (!auto err =3D FromString(x, "123")) =C2=A0 // This relie=
s on extended<br>
> if-initalizer functionality being suggested!<br>
> =C2=A0 =C2=A0 ... handle error using error code available from err whi=
ch I guess is<br>
> basically an exception_ptr;<br>
><br>
><br>
><br>
> vs.<br>
><br>
> int x;<br>
> auto tmp =3D FromString<int>("123");<br>
> if (tmp)<br>
> =C2=A0 =C2=A0 x =3D tmp.value();<br>
><br>
> else<br>
> =C2=A0 =C2=A0 ... handle error using tmp.get_error() or something like=
that.<br>
><br>
><br>
> Well, in the case that you need to get at the specific error code the<=
br>
> difference in clumsiness is maybe not that great. However please note =
that<br>
> my destructor exception gets thrown even if the first conversion didn&=
#39;t<br>
> fail, the throw is just caused by the non-checking of the result, whic=
h the<br>
> alternative code using value() which throws if the conversion went sou=
th<br>
> does not provide.<br>
><br>
> As the previous speaker I'm however leaning towards wishing for a =
language<br>
> feature that can deliver this as a compile time error. This either req=
uires<br>
> a very specific language feature for just this case (unlikely to happe=
n) or<br>
> maybe we could figure out some constexpr on steroids which can feed in=
to a<br>
> static_assert? Something like being to able to return a pair where one=
of<br>
> the two is constexpr and the other not. The constexpr member must of c=
ourse<br>
> be evaluated at compile time and thus triggers the static_assert as ne=
eded.<br>
> I'm not fully up to speed with the newest constexpr stuff like con=
stexpr<br>
> constructors, maybe this is already doable? A sketch:<br>
><br>
> template<typename T> struct static_check_ret {<br>
> =C2=A0 =C2=A0 T retval;<br>
><br>
> =C2=A0 =C2=A0 ~static_check_ret() { static_assert(checked, "Retur=
n code never<br>
> checked"); }<br>
> =C2=A0 =C2=A0 operator bool () { checked =3D true; }<br>
> =C2=A0 =C2=A0 T value_or(const T& other) { checked =3D true; }<br>
> =C2=A0 =C2=A0 mutable constexpr bool checked =3D false; =C2=A0// But n=
ow this one is only a<br>
> little constexpr! The initialization sets it false but then it can be =
set<br>
> true when the COMPILER sees use of the methods that sets it true!<br>
> }<br>
> If anyone sees this as valuable (I seriously doubt that) the variable =
could<br>
> possibly be declared mutable constexpr to allow this type of compile t=
ime<br>
> magic.<br>
> The great thing would of course be that we could make sure the return =
code<br>
> is checked at all callsites (or ignored of course) without incurring r=
untime<br>
> overhead. The limitations of what needs to be inline for the compiler =
to be<br>
> able to do this does not look appealing though. Also of course the<br>
> assignments to a mutable constexpr must be to constexpr data and not i=
nside<br>
> some non-constexpr condition. Note that of course the entire operator =
bool()<br>
> and value_or() are not constexpr!<br>
><br>
> Can anyone come up with additional use cases for such a construct? Is =
it<br>
> even worth contemplating? Still better than a special solution for jus=
t the<br>
> return value checking enforcement case, in my mind. It looks that it c=
ould<br>
> have some use in general in template metaprogramming.<br>
><br>
> Having written this it seems quite apparent that this is a really scar=
y<br>
> little feature to standardize and for compiler vendors to implement...=
I<br>
> just post this message as someone else may find more prominent use cas=
es<br>
> that could motivate the standardization and implementation effort. Ano=
ther<br>
> hope I have is that someone could find a way out to implement this wit=
h<br>
> today's definition of constexpr (we're now in 2014 after all..=
..), which<br>
> would be great.<br>
><br>
><br>
> Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir B=
atov:<br>
>><br>
>> Vicente et al,<br>
>><br>
>> Thanks for the info and the links. Much appreciated. The concept/i=
dea and<br>
>> A. Alexandresku presentation look quite interesting as IMO it'=
d be quite<br>
>> applicable in string-to-T conversions that I myself was somewhat<b=
r>
>> interested/involved in. Not sure how it pans out in practice. I su=
spect<br>
>> generic implementation might be difficult to achieve. Will watch t=
he space<br>
>> for more documentation/info. =C2=A0A website or a list that I shou=
ld be<br>
>> watching/monitoring for updates?<br>
>><br>
>> Thanks,<br>
>> V.<br>
>><br>
>> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet=
Escriba<br>
>> wrote:<br>
>>><br>
>>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :<br=
>
>>><br>
>>><br>
>>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <<a href=3D=
"mailto:vb.ma...@gmail.com">vb.ma...@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Tried getting more info about Boost.Expected following the=
links<br>
>>>> provided. Did not get far. Is there any documentation/disc=
ussion on the<br>
>>>> topic? Boost list maybe?<br>
>>><br>
>>><br>
>>> In case that helps:<br>
>>> The first time I heard about Expected it was in this presentat=
ion from<br>
>>> Alexandrescu, the first part (there are 3 parts), which expose=
s the rational<br>
>>> of such type:<br>
>>><br>
>>> <a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Bey=
ond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C" target=3D"_bla=
nk">http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alex=
andrescu-Systematic-Error-Handling-in-C</a><br>
>>><br>
>>> I believe the Boost.Expected implementation is not exactly sim=
ilar but<br>
>>> share the same base.<br>
>>><br>
>>> Yes, Boost.Expected started based on the presentation from Ale=
xandrescu.<br>
>>> It has been extended and redesigned to take care of some featu=
res found on<br>
>>> the future proposals and in the Haskell Monads.<br>
>>><br>
>>> The proposal is not yet ready because we want to integrate bet=
ter the<br>
>>> Monads concept.<br>
>>><br>
>>> Best,<br>
>>> Vicente<br>
<span class=3D"HOEnZb"><font color=3D"#888888">><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to a topic in the=
<br>
> Google Groups "ISO C++ Standard - Future Proposals" group.<b=
r>
> To unsubscribe from this topic, visit<br>
> <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/260PWIq_7u0/unsubscribe" target=3D"_blank">https://groups.google.com/a/is=
ocpp.org/d/topic/std-proposals/260PWIq_7u0/unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to<br=
>
> <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposal=
s+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d0447f0ee098a7904f14c9517--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 31 Jan 2014 18:31:56 -0500
Raw View
On 2014-01-31 17:54, Bengt Gustafsson wrote:
> As the previous speaker I'm however leaning towards wishing for a language
> feature that can deliver this as a compile time error. This either requires
> a very specific language feature for just this case (unlikely to happen)
Maybe. OTOH it would be a very useful language feature, and is already
at least partly implemented by GCC in the form of the warn_unused_result
attribute.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 1 Feb 2014 13:30:31 +1100
Raw View
> ... there's quite a lot of documented success for libraries ...
> This is all about making the call site pretty / understandable / easy to
> maintain. Sometimes the best way to do that is with out parameters.
> Sometimes the best way is to return a tuple or some other type.
I'd most likely try and support all that with an example... a credible
example... something from std, boost, ... or a few examples ... given
its sheer magnitude.
V.
On Sat, Feb 1, 2014 at 10:31 AM, Billy O'Neal <billy.oneal@gmail.com> wrote=
:
> It depends. If you are using out parameters just for the sake of passing =
out
> parameters, then sure. But there's quite a lot of documented success for
> libraries that give code like:
>
> int result;
> if (foo.TryParse(result))
> {
> // use result
> }
>
> even in other high level languages where out parameters are discouraged
> (e.g. Java / C#).
>
> This is all about making the call site pretty / understandable / easy to
> maintain. Sometimes the best way to do that is with out parameters.
> Sometimes the best way is to return a tuple or some other type.
>
> Billy O'Neal
> https://github.com/BillyONeal/
> http://stackoverflow.com/users/82320/billy-oneal
>
>
> On Fri, Jan 31, 2014 at 3:09 PM, Vladimir Batov <vb.mail.247@gmail.com>
> wrote:
>>
>> > ... the destination as a reference parameter...
>>
>> My *very personal* view is that, if you want your proposal to be
>> seriously considered by wide C++ community and to get anywhere, you
>> simply have to forget the Pascal-style of passing return parameters
>> in. IMO it goes so much against the whole C++ philosophy and style.
>> OTOH I can't think of one single std. library component doing that.
>> Please do not get me wrong. I am not judging/criticizing your
>> programming style and personal preferences. Only saying that IMO that
>> choice will push so many people away (for practical, stylistic, etc.
>> reasons) even before we get into a serious discussion.
>>
>> Just my 2c.
>> V.
>>
>>
>>
>> On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson
>> <bengt.gustafsson@beamways.com> wrote:
>> > I think it must be easy to do easy things. My first choice would still
>> > be to
>> > have the destination as a reference parameter as you don't have to mes=
s
>> > with
>> > the explicit template type and match it to the variable. This basicall=
y
>> > leaves my original error_return class. This allows checking the return
>> > value
>> > with a surrounding if.
>> >
>> > I can't see a way to actually return both the value and the possible
>> > error
>> > code without using an extra named variable, although of course it can =
be
>> > auto typed. Together with the explicit template parameter it builds
>> > clumsiness:
>> >
>> > int x;
>> > if (!FromString(x, "123"))
>> > ... handle error without using error code;
>> >
>> > or
>> > int x;
>> > if (!auto err =3D FromString(x, "123")) // This relies on extended
>> > if-initalizer functionality being suggested!
>> > ... handle error using error code available from err which I guess
>> > is
>> > basically an exception_ptr;
>> >
>> >
>> >
>> > vs.
>> >
>> > int x;
>> > auto tmp =3D FromString<int>("123");
>> > if (tmp)
>> > x =3D tmp.value();
>> >
>> > else
>> > ... handle error using tmp.get_error() or something like that.
>> >
>> >
>> > Well, in the case that you need to get at the specific error code the
>> > difference in clumsiness is maybe not that great. However please note
>> > that
>> > my destructor exception gets thrown even if the first conversion didn'=
t
>> > fail, the throw is just caused by the non-checking of the result, whic=
h
>> > the
>> > alternative code using value() which throws if the conversion went sou=
th
>> > does not provide.
>> >
>> > As the previous speaker I'm however leaning towards wishing for a
>> > language
>> > feature that can deliver this as a compile time error. This either
>> > requires
>> > a very specific language feature for just this case (unlikely to happe=
n)
>> > or
>> > maybe we could figure out some constexpr on steroids which can feed in=
to
>> > a
>> > static_assert? Something like being to able to return a pair where one
>> > of
>> > the two is constexpr and the other not. The constexpr member must of
>> > course
>> > be evaluated at compile time and thus triggers the static_assert as
>> > needed.
>> > I'm not fully up to speed with the newest constexpr stuff like constex=
pr
>> > constructors, maybe this is already doable? A sketch:
>> >
>> > template<typename T> struct static_check_ret {
>> > T retval;
>> >
>> > ~static_check_ret() { static_assert(checked, "Return code never
>> > checked"); }
>> > operator bool () { checked =3D true; }
>> > T value_or(const T& other) { checked =3D true; }
>> > mutable constexpr bool checked =3D false; // But now this one is =
only
>> > a
>> > little constexpr! The initialization sets it false but then it can be
>> > set
>> > true when the COMPILER sees use of the methods that sets it true!
>> > }
>> > If anyone sees this as valuable (I seriously doubt that) the variable
>> > could
>> > possibly be declared mutable constexpr to allow this type of compile
>> > time
>> > magic.
>> > The great thing would of course be that we could make sure the return
>> > code
>> > is checked at all callsites (or ignored of course) without incurring
>> > runtime
>> > overhead. The limitations of what needs to be inline for the compiler =
to
>> > be
>> > able to do this does not look appealing though. Also of course the
>> > assignments to a mutable constexpr must be to constexpr data and not
>> > inside
>> > some non-constexpr condition. Note that of course the entire operator
>> > bool()
>> > and value_or() are not constexpr!
>> >
>> > Can anyone come up with additional use cases for such a construct? Is =
it
>> > even worth contemplating? Still better than a special solution for jus=
t
>> > the
>> > return value checking enforcement case, in my mind. It looks that it
>> > could
>> > have some use in general in template metaprogramming.
>> >
>> > Having written this it seems quite apparent that this is a really scar=
y
>> > little feature to standardize and for compiler vendors to implement...=
I
>> > just post this message as someone else may find more prominent use cas=
es
>> > that could motivate the standardization and implementation effort.
>> > Another
>> > hope I have is that someone could find a way out to implement this wit=
h
>> > today's definition of constexpr (we're now in 2014 after all...), whic=
h
>> > would be great.
>> >
>> >
>> > Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir
>> > Batov:
>> >>
>> >> Vicente et al,
>> >>
>> >> Thanks for the info and the links. Much appreciated. The concept/idea
>> >> and
>> >> A. Alexandresku presentation look quite interesting as IMO it'd be
>> >> quite
>> >> applicable in string-to-T conversions that I myself was somewhat
>> >> interested/involved in. Not sure how it pans out in practice. I suspe=
ct
>> >> generic implementation might be difficult to achieve. Will watch the
>> >> space
>> >> for more documentation/info. A website or a list that I should be
>> >> watching/monitoring for updates?
>> >>
>> >> Thanks,
>> >> V.
>> >>
>> >> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet
>> >> Escriba
>> >> wrote:
>> >>>
>> >>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
>> >>>
>> >>>
>> >>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Tried getting more info about Boost.Expected following the links
>> >>>> provided. Did not get far. Is there any documentation/discussion on
>> >>>> the
>> >>>> topic? Boost list maybe?
>> >>>
>> >>>
>> >>> In case that helps:
>> >>> The first time I heard about Expected it was in this presentation fr=
om
>> >>> Alexandrescu, the first part (there are 3 parts), which exposes the
>> >>> rational
>> >>> of such type:
>> >>>
>> >>>
>> >>> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-A=
lexandrescu-Systematic-Error-Handling-in-C
>> >>>
>> >>> I believe the Boost.Expected implementation is not exactly similar b=
ut
>> >>> share the same base.
>> >>>
>> >>> Yes, Boost.Expected started based on the presentation from
>> >>> Alexandrescu.
>> >>> It has been extended and redesigned to take care of some features
>> >>> found on
>> >>> the future proposals and in the Haskell Monads.
>> >>>
>> >>> The proposal is not yet ready because we want to integrate better th=
e
>> >>> Monads concept.
>> >>>
>> >>> Best,
>> >>> Vicente
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> >
>> > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7=
u0/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > std-proposals+unsubscribe@isocpp.org.
>> > To post to this group, send email to std-proposals@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>>
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Fri, 31 Jan 2014 19:21:40 -0800 (PST)
Raw View
------=_Part_2513_8281892.1391224900939
Content-Type: text/plain; charset=UTF-8
On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R. wrote:
>
> Maybe you are looking for the support given in the header <system_error>
> from the error handling library.
>
Perhaps, but in many cases I like to specify my own set of error codes.
Using an enum is even better because you have the compiler help you ensure
you handle them all with -Wswitch.
On Monday, January 27, 2014 3:54:01 PM UTC-5, Vicente J. Botet Escriba
wrote:
>
> Have you heard about the expected proposal?
>
>
No, but I saw Alexandrescu's talk about it. Its an interesting idea.
On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa wrote:
>
> ...
> The above isn't exactly what we had. The above is slightly more like an
> exception allowing any type to be stored in the error. We only permitted
> storing our base complex error type (similar to std::system_error in some
> regards but avoided any heap allocation and had a bunch of features
> irrelevant to this discussion). But it gives the general gist of how it
> could be used in a more generic setting as an alternative to exceptions. It
> obviously doesn't solve issues arising from avoiding using exceptions in
> constructors and overloaded operators though.
>
>
I like your idea. A thread-local error state such as errno is not so evil
as people make it out to be. As you say it certainly makes the stack
propagation (aka the football part) easier. There was a lot of backlash
against the errno pattern in the string-to-int thread. One thing I'd be
curious about is what updating thread local state means for inlining. What
kind of optimization is inhibited? The compiler can easily optimize out an
unused return value but for a global/thread-local, it has no idea what the
side effects could be.
On Wednesday, January 29, 2014 11:29:40 AM UTC-5, Bengt Gustafsson wrote:
> Boost::Expected is similar to optional but adds the capability to provide
> an exception as well.
>
> In many cases APIs have only an error value to return. I suggest this
> class (which I initially presented in a thread from_string). The advantage
> is that you can make sure that the error situation is handled in some way.
> I would like this to happen at compile time but it is beyond me to find out
> how (without messing up the syntax you have to write every time you use the
> feature).
>
>
You probably want this as a move only type no? You don't want people
inadvertently making copies and then having of the destructors throw.
Why not just call std::terminate() instead of throwing? Then you also don't
have complications with having a throwing destructor. I'd also augment this
to accept an enum of error codes which can be used to inform the user of
why the failure occurred.
While I like your idea, I think enforcing the programmer checked the return
value belongs in the compiler error/warning domain. I understand though
with the current state of things runtime checking might be the best we can
do. It also looks like the runtime enforcement you've developed can easily
be optimized out which is good.
What are the performance implications of make_exception_ptr()? For
something simple like string-to-int, I'd really want to have maximum
performance on the correct path and error paths.
On Friday, January 31, 2014 6:09:39 PM UTC-5, Vladimir Batov wrote:
>
> > ... the destination as a reference parameter...
>
> My *very personal* view is that, if you want your proposal to be
> seriously considered by wide C++ community and to get anywhere, you
> simply have to forget the Pascal-style of passing return parameters
> in. IMO it goes so much against the whole C++ philosophy and style.
>
C++ philosophy? Says who? I don't give a damn about past precedents. All
other things being equal, convention should be followed. All other things
being very unequal, convention should be abandoned in favor of superior
tools and interfaces. Many things that used to be considered good practice
and style are now laughable. We should always keep our minds open and
design the best tools.
> OTOH I can't think of one single std. library component doing that.
> Please do not get me wrong. I am not judging/criticizing your
> programming style and personal preferences. Only saying that IMO that
> choice will push so many people away (for practical, stylistic, etc.
> reasons) even before we get into a serious discussion.
>
> Just my 2c.
> V.
>
I like reference out parameters for the same reasons as the previous
poster. They work very well for precedural interfaces with overloading.
int val;
if(!fromString("1234", val)) {
//handle error
}
The above does the conversion and checks for errors in one line of code. It
takes advantage of overloading. Its also in my opinion very elegant and
simple.
These are redundant and require either exceptions or reusing a valid int
value to denote errors. The first requires special care if we change the
type of val. Imagine changing val to long. The code still compiles just
fine. The second version avoids the potential bug of changing the type of
val but is verbose.
int val = fromString<int>("1234");
int val = fromString<decltype(val)>("1234"):
These still use out parameters but require more code:
int val = fromString<int>("1234", was_successful);
if(was_successful) {
}
The only major disadvantage to reference out parameters as mentioned in the
other thread is that you can't initialize things.
For class types, the reference out parameter really doesn't work so well.
Sometimes you really need to use the constructor instead of default
constructing and then assigning later. That is not the case here as we are
talking about assigning to simple ints and floats.
For const, there are some workarounds. For example if you are parsing a lot
of ints, you can use one variable to parse into. I'll admit this is a
little less ideal (one extra variable in the scope, eww!).
int val;
if(!fromString("1234",val)) {
}
const int x = val;
if(!fromString("56",val)) {
}
const int y = val;
if(!fromString("78",val)) {
}
int z = val;
As for the new ideas of std::optional, and expected, I haven't quite come
to an solid opinion on those yet. It does require a bit more code to unpack
the errors and return values out of those.
Remember this discussion is about C like procedural interfaces where the
costs of exceptions is high so we have to fallback on return values and/or
out parameters. Like we used to call some C++ programming style "C with
classes", think of this as "C with templates, overloading, and possibly
constexpr"
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2513_8281892.1391224900939
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R.=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-lef=
t-style: solid; padding-left: 1ex;"><div dir=3D"ltr">Maybe you are looking =
for the support given in the header <system_error> from the error han=
dling library.</div></blockquote><div><br></div><div>Perhaps, but in many c=
ases I like to specify my own set of error codes. Using an enum is even bet=
ter because you have the compiler help you ensure you handle them all with =
-Wswitch. </div><div><br></div><div><br>On Monday, January 27, 2014 3:=
54:01 PM UTC-5, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-le=
ft-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"=
><div bgcolor=3D"#FFFFFF" text=3D"#000000">Have you heard about the expecte=
d proposal?<br><br></div></blockquote><div><br>No, but I saw Alexandrescu's=
talk about it. Its an interesting idea. </div></div><div><br></div><d=
iv><br>On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-=
left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: =
solid; padding-left: 1ex;"><div dir=3D"ltr"><div>...</div><div>The above is=
n't exactly what we had. The above is slightly more like an exception allow=
ing any type to be stored in the error. We only permitted storing our base =
complex error type (similar to std::system_error in some regards but avoide=
d any heap allocation and had a bunch of features irrelevant to this discus=
sion). But it gives the general gist of how it could be used in a more gene=
ric setting as an alternative to exceptions. It obviously doesn't solve iss=
ues arising from avoiding using exceptions in constructors and overloaded o=
perators though.</div><div><br></div></div></blockquote><div><br></div><div=
>I like your idea. A thread-local error state such as errno is not so evil =
as people make it out to be. As you say it certainly makes the stack propag=
ation (aka the football part) easier. There was a lot of backlash against t=
he errno pattern in the string-to-int thread. One thing I'd be curious abou=
t is what updating thread local state means for inlining. What kind of opti=
mization is inhibited? The compiler can easily optimize out an unused retur=
n value but for a global/thread-local, it has no idea what the side effects=
could be.</div><div><br></div><div> <span style=3D"font-size: 13px;">=
On Wednesday, January 29, 2014 11:29:40 AM UTC-5, Bengt Gustafsson wrote:</=
span></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border=
-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">Boost::Expected is=
similar to optional but adds the capability to provide an exception as wel=
l.<div><br></div><div>In many cases APIs have only an error value to return=
.. I suggest this class (which I initially presented in a thread from_string=
). The advantage is that you can make sure that the error situation is hand=
led in some way. I would like this to happen at compile time but it is beyo=
nd me to find out how (without messing up the syntax you have to write ever=
y time you use the feature).</div><div><br></div></div></blockquote><div><b=
r></div><div>You probably want this as a move only type no? You don't want =
people inadvertently making copies and then having of the destructors throw=
..<br><br></div><div>Why not just call std::terminate() instead of throwing?=
Then you also don't have complications with having a throwing destructor. =
I'd also augment this to accept an enum of error codes which can be used to=
inform the user of why the failure occurred.</div><div><br></div><div>Whil=
e I like your idea, I think enforcing the programmer checked the return val=
ue belongs in the compiler error/warning domain. I understand though with t=
he current state of things runtime checking might be the best we can do. It=
also looks like the runtime enforcement you've developed can easily be opt=
imized out which is good.</div><div><br></div><div>What are the performance=
implications of make_exception_ptr()? For something simple like string-to-=
int, I'd really want to have maximum performance on the correct path and er=
ror paths.</div><div><br><br>On Friday, January 31, 2014 6:09:39 PM UTC-5, =
Vladimir Batov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 20=
4); border-left-style: solid; padding-left: 1ex;">> ... the destination =
as a reference parameter... <br><br>My *very personal* view is that, i=
f you want your proposal to be <br>seriously considered by wide C++ co=
mmunity and to get anywhere, you <br>simply have to forget the Pascal-=
style of passing return parameters <br>in. IMO it goes so much against=
the whole C++ philosophy and style. <br></blockquote><div><br></div><=
div>C++ philosophy? Says who? I don't give a damn about past precedents. Al=
l other things being equal, convention should be followed. All other things=
being very unequal, convention should be abandoned in favor of superior to=
ols and interfaces. Many things that used to be considered good practice an=
d style are now laughable. We should always keep our minds open and design =
the best tools.</div><div> </div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color:=
rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">OTOH I c=
an't think of one single std. library component doing that. <br>Please=
do not get me wrong. I am not judging/criticizing your <br>programmin=
g style and personal preferences. Only saying that IMO that <br>choice=
will push so many people away (for practical, stylistic, etc. <br>rea=
sons) even before we get into a serious discussion. <br><br>Just my 2c=
.. <br>V. <br></blockquote></div><div><br></div><div>I like refere=
nce out parameters for the same reasons as the previous poster. They work v=
ery well for precedural interfaces with overloading.</div><div><br></div><d=
iv>int val;</div><div>if(!fromString("1234", val)) {<br> //handle err=
or</div><div>}</div><div><br></div><div>The above does the conversion and c=
hecks for errors in one line of code. It takes advantage of overloading. It=
s also in my opinion very elegant and simple.</div><div><br></div><div>Thes=
e are redundant and require either exceptions or reusing a valid int value =
to denote errors. The first requires special care if we change the type of =
val. Imagine changing val to long. The code still compiles just fine. The s=
econd version avoids the potential bug of changing the type of val but is v=
erbose.</div><div>int val =3D fromString<int>("1234");</div><div>int =
val =3D fromString<decltype(val)>("1234"):</div><div><br></div><div>T=
hese still use out parameters but require more code:</div><div>int val =3D =
fromString<int>("1234", was_successful);</div><div>if(was_successful)=
{<br>}</div><div><br></div><div>The only major disadvantage to reference o=
ut parameters as mentioned in the other thread is that you can't initialize=
things. </div></div><div><br></div><div>For class types, the referenc=
e out parameter really doesn't work so well. Sometimes you really need to u=
se the constructor instead of default constructing and then assigning later=
.. That is not the case here as we are talking about assigning to simple int=
s and floats.</div><div><br></div><div>For const, there are some workaround=
s. For example if you are parsing a lot of ints, you can use one variable t=
o parse into. I'll admit this is a little less ideal (one extra variable in=
the scope, eww!).</div><div><br></div><div>int val;</div><div>if(!fromStri=
ng("1234",val)) {<br>}</div><div>const int x =3D val;</div><div><div>if(!fr=
omString("56",val)) {<br>}</div><div>const int y =3D val;</div></div><div><=
div>if(!fromString("78",val)) {<br>}</div><div>int z =3D val;</div></div><d=
iv><br></div><div>As for the new ideas of std::optional, and expected, I ha=
ven't quite come to an solid opinion on those yet. It does require a bit mo=
re code to unpack the errors and return values out of those.</div><div><br>=
</div><div>Remember this discussion is about C like procedural interfaces w=
here the costs of exceptions is high so we have to fallback on return value=
s and/or out parameters. Like we used to call some C++ programming style "C=
with classes", think of this as "C with templates, overloading, and possib=
ly constexpr"</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2513_8281892.1391224900939--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Fri, 31 Jan 2014 19:30:45 -0800
Raw View
--047d7b5d2ea4dab07304f14fec78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hmmmm... I stand slightly corrected. I was under the impression that Java's
int parsing worked this way; but looking now it appears that it throws
exceptions. C# has gone this route though:
http://msdn.microsoft.com/en-us/library/f02979c7(v=3Dvs.110).aspx
and I've never heard anyone complain about it there. (In contrast, I've
heard plenty of people complain about the interface that throws exceptions)
boost::spirit::karma also goes this route:
http://www.boost.org/doc/libs/1_48_0/libs/spirit/doc/html/spirit/qi/referen=
ce/parse_api/iterator_api.html
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Fri, Jan 31, 2014 at 6:30 PM, Vladimir Batov <vb.mail.247@gmail.com>wrot=
e:
> > ... there's quite a lot of documented success for libraries ...
> > This is all about making the call site pretty / understandable / easy t=
o
> > maintain. Sometimes the best way to do that is with out parameters.
> > Sometimes the best way is to return a tuple or some other type.
>
> I'd most likely try and support all that with an example... a credible
> example... something from std, boost, ... or a few examples ... given
> its sheer magnitude.
>
> V.
>
> On Sat, Feb 1, 2014 at 10:31 AM, Billy O'Neal <billy.oneal@gmail.com>
> wrote:
> > It depends. If you are using out parameters just for the sake of passin=
g
> out
> > parameters, then sure. But there's quite a lot of documented success fo=
r
> > libraries that give code like:
> >
> > int result;
> > if (foo.TryParse(result))
> > {
> > // use result
> > }
> >
> > even in other high level languages where out parameters are discouraged
> > (e.g. Java / C#).
> >
> > This is all about making the call site pretty / understandable / easy t=
o
> > maintain. Sometimes the best way to do that is with out parameters.
> > Sometimes the best way is to return a tuple or some other type.
> >
> > Billy O'Neal
> > https://github.com/BillyONeal/
> > http://stackoverflow.com/users/82320/billy-oneal
> >
> >
> > On Fri, Jan 31, 2014 at 3:09 PM, Vladimir Batov <vb.mail.247@gmail.com>
> > wrote:
> >>
> >> > ... the destination as a reference parameter...
> >>
> >> My *very personal* view is that, if you want your proposal to be
> >> seriously considered by wide C++ community and to get anywhere, you
> >> simply have to forget the Pascal-style of passing return parameters
> >> in. IMO it goes so much against the whole C++ philosophy and style.
> >> OTOH I can't think of one single std. library component doing that.
> >> Please do not get me wrong. I am not judging/criticizing your
> >> programming style and personal preferences. Only saying that IMO that
> >> choice will push so many people away (for practical, stylistic, etc.
> >> reasons) even before we get into a serious discussion.
> >>
> >> Just my 2c.
> >> V.
> >>
> >>
> >>
> >> On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson
> >> <bengt.gustafsson@beamways.com> wrote:
> >> > I think it must be easy to do easy things. My first choice would sti=
ll
> >> > be to
> >> > have the destination as a reference parameter as you don't have to
> mess
> >> > with
> >> > the explicit template type and match it to the variable. This
> basically
> >> > leaves my original error_return class. This allows checking the retu=
rn
> >> > value
> >> > with a surrounding if.
> >> >
> >> > I can't see a way to actually return both the value and the possible
> >> > error
> >> > code without using an extra named variable, although of course it ca=
n
> be
> >> > auto typed. Together with the explicit template parameter it builds
> >> > clumsiness:
> >> >
> >> > int x;
> >> > if (!FromString(x, "123"))
> >> > ... handle error without using error code;
> >> >
> >> > or
> >> > int x;
> >> > if (!auto err =3D FromString(x, "123")) // This relies on extended
> >> > if-initalizer functionality being suggested!
> >> > ... handle error using error code available from err which I gue=
ss
> >> > is
> >> > basically an exception_ptr;
> >> >
> >> >
> >> >
> >> > vs.
> >> >
> >> > int x;
> >> > auto tmp =3D FromString<int>("123");
> >> > if (tmp)
> >> > x =3D tmp.value();
> >> >
> >> > else
> >> > ... handle error using tmp.get_error() or something like that.
> >> >
> >> >
> >> > Well, in the case that you need to get at the specific error code th=
e
> >> > difference in clumsiness is maybe not that great. However please not=
e
> >> > that
> >> > my destructor exception gets thrown even if the first conversion
> didn't
> >> > fail, the throw is just caused by the non-checking of the result,
> which
> >> > the
> >> > alternative code using value() which throws if the conversion went
> south
> >> > does not provide.
> >> >
> >> > As the previous speaker I'm however leaning towards wishing for a
> >> > language
> >> > feature that can deliver this as a compile time error. This either
> >> > requires
> >> > a very specific language feature for just this case (unlikely to
> happen)
> >> > or
> >> > maybe we could figure out some constexpr on steroids which can feed
> into
> >> > a
> >> > static_assert? Something like being to able to return a pair where o=
ne
> >> > of
> >> > the two is constexpr and the other not. The constexpr member must of
> >> > course
> >> > be evaluated at compile time and thus triggers the static_assert as
> >> > needed.
> >> > I'm not fully up to speed with the newest constexpr stuff like
> constexpr
> >> > constructors, maybe this is already doable? A sketch:
> >> >
> >> > template<typename T> struct static_check_ret {
> >> > T retval;
> >> >
> >> > ~static_check_ret() { static_assert(checked, "Return code never
> >> > checked"); }
> >> > operator bool () { checked =3D true; }
> >> > T value_or(const T& other) { checked =3D true; }
> >> > mutable constexpr bool checked =3D false; // But now this one i=
s
> only
> >> > a
> >> > little constexpr! The initialization sets it false but then it can b=
e
> >> > set
> >> > true when the COMPILER sees use of the methods that sets it true!
> >> > }
> >> > If anyone sees this as valuable (I seriously doubt that) the variabl=
e
> >> > could
> >> > possibly be declared mutable constexpr to allow this type of compile
> >> > time
> >> > magic.
> >> > The great thing would of course be that we could make sure the retur=
n
> >> > code
> >> > is checked at all callsites (or ignored of course) without incurring
> >> > runtime
> >> > overhead. The limitations of what needs to be inline for the compile=
r
> to
> >> > be
> >> > able to do this does not look appealing though. Also of course the
> >> > assignments to a mutable constexpr must be to constexpr data and not
> >> > inside
> >> > some non-constexpr condition. Note that of course the entire operato=
r
> >> > bool()
> >> > and value_or() are not constexpr!
> >> >
> >> > Can anyone come up with additional use cases for such a construct? I=
s
> it
> >> > even worth contemplating? Still better than a special solution for
> just
> >> > the
> >> > return value checking enforcement case, in my mind. It looks that it
> >> > could
> >> > have some use in general in template metaprogramming.
> >> >
> >> > Having written this it seems quite apparent that this is a really
> scary
> >> > little feature to standardize and for compiler vendors to
> implement... I
> >> > just post this message as someone else may find more prominent use
> cases
> >> > that could motivate the standardization and implementation effort.
> >> > Another
> >> > hope I have is that someone could find a way out to implement this
> with
> >> > today's definition of constexpr (we're now in 2014 after all...),
> which
> >> > would be great.
> >> >
> >> >
> >> > Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev Vladimir
> >> > Batov:
> >> >>
> >> >> Vicente et al,
> >> >>
> >> >> Thanks for the info and the links. Much appreciated. The concept/id=
ea
> >> >> and
> >> >> A. Alexandresku presentation look quite interesting as IMO it'd be
> >> >> quite
> >> >> applicable in string-to-T conversions that I myself was somewhat
> >> >> interested/involved in. Not sure how it pans out in practice. I
> suspect
> >> >> generic implementation might be difficult to achieve. Will watch th=
e
> >> >> space
> >> >> for more documentation/info. A website or a list that I should be
> >> >> watching/monitoring for updates?
> >> >>
> >> >> Thanks,
> >> >> V.
> >> >>
> >> >> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente J. Botet
> >> >> Escriba
> >> >> wrote:
> >> >>>
> >> >>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9crit :
> >> >>>
> >> >>>
> >> >>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <vb.ma...@gmail.co=
m
> >
> >> >>> wrote:
> >> >>>>
> >> >>>> Tried getting more info about Boost.Expected following the links
> >> >>>> provided. Did not get far. Is there any documentation/discussion =
on
> >> >>>> the
> >> >>>> topic? Boost list maybe?
> >> >>>
> >> >>>
> >> >>> In case that helps:
> >> >>> The first time I heard about Expected it was in this presentation
> from
> >> >>> Alexandrescu, the first part (there are 3 parts), which exposes th=
e
> >> >>> rational
> >> >>> of such type:
> >> >>>
> >> >>>
> >> >>>
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
> >> >>>
> >> >>> I believe the Boost.Expected implementation is not exactly similar
> but
> >> >>> share the same base.
> >> >>>
> >> >>> Yes, Boost.Expected started based on the presentation from
> >> >>> Alexandrescu.
> >> >>> It has been extended and redesigned to take care of some features
> >> >>> found on
> >> >>> the future proposals and in the Haskell Monads.
> >> >>>
> >> >>> The proposal is not yet ready because we want to integrate better
> the
> >> >>> Monads concept.
> >> >>>
> >> >>> Best,
> >> >>> Vicente
> >> >
> >> > --
> >> >
> >> > ---
> >> > You received this message because you are subscribed to a topic in t=
he
> >> > Google Groups "ISO C++ Standard - Future Proposals" group.
> >> > To unsubscribe from this topic, visit
> >> >
> >> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe
> .
> >> > To unsubscribe from this group and all its topics, send an email to
> >> > std-proposals+unsubscribe@isocpp.org.
> >> > To post to this group, send email to std-proposals@isocpp.org.
> >> > Visit this group at
> >> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >>
> >> --
> >>
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "ISO C++ Standard - Future Proposals" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to std-proposals+unsubscribe@isocpp.org.
> >>
> >> To post to this group, send email to std-proposals@isocpp.org.
> >> Visit this group at
> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.
> >
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to
> > std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b5d2ea4dab07304f14fec78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hmmmm... I stand slightly corrected. I was under the =
impression that Java's int parsing worked this way; but looking now it =
appears that it throws exceptions. C# has gone this route though:</div><div=
>
<br></div><div><a href=3D"http://msdn.microsoft.com/en-us/library/f02979c7(=
v=3Dvs.110).aspx">http://msdn.microsoft.com/en-us/library/f02979c7(v=3Dvs.1=
10).aspx</a></div><div><br></div><div>and I've never heard anyone compl=
ain about it there. (In contrast, I've heard plenty of people complain =
about the interface that throws exceptions)</div>
<div><br></div><div>boost::spirit::karma also goes this route: <a href=3D"h=
ttp://www.boost.org/doc/libs/1_48_0/libs/spirit/doc/html/spirit/qi/referenc=
e/parse_api/iterator_api.html">http://www.boost.org/doc/libs/1_48_0/libs/sp=
irit/doc/html/spirit/qi/reference/parse_api/iterator_api.html</a></div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Fri, Jan 31, 2014 at 6:30 PM, Vladimi=
r Batov <span dir=3D"ltr"><<a href=3D"mailto:vb.mail.247@gmail.com" targ=
et=3D"_blank">vb.mail.247@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
> ... there's quite a lot of documented success for libraries ...<br=
>
<div class=3D"im">> This is all about making the call site pretty / unde=
rstandable / easy to<br>
> maintain. Sometimes the best way to do that is with out parameters.<br=
>
> Sometimes the best way is to return a tuple or some other type.<br>
<br>
</div>I'd most likely try and support all that with an example... a cre=
dible<br>
example... something from std, boost, ... or a few examples ... given<br>
its sheer magnitude.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
V.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Sat, Feb 1, 2014 at 10:31 AM, Billy O'Neal <<a href=3D"mailto:bil=
ly.oneal@gmail.com">billy.oneal@gmail.com</a>> wrote:<br>
> It depends. If you are using out parameters just for the sake of passi=
ng out<br>
> parameters, then sure. But there's quite a lot of documented succe=
ss for<br>
> libraries that give code like:<br>
><br>
> int result;<br>
> if (foo.TryParse(result))<br>
> {<br>
> // use result<br>
> }<br>
><br>
> even in other high level languages where out parameters are discourage=
d<br>
> (e.g. Java / C#).<br>
><br>
> This is all about making the call site pretty / understandable / easy =
to<br>
> maintain. Sometimes the best way to do that is with out parameters.<br=
>
> Sometimes the best way is to return a tuple or some other type.<br>
><br>
> Billy O'Neal<br>
> <a href=3D"https://github.com/BillyONeal/" target=3D"_blank">https://g=
ithub.com/BillyONeal/</a><br>
> <a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a><br>
><br>
><br>
> On Fri, Jan 31, 2014 at 3:09 PM, Vladimir Batov <<a href=3D"mailto:=
vb.mail.247@gmail.com">vb.mail.247@gmail.com</a>><br>
> wrote:<br>
>><br>
>> > ... the destination as a reference parameter...<br>
>><br>
>> My *very personal* view is that, if you want your proposal to be<b=
r>
>> seriously considered by wide C++ community and to get anywhere, yo=
u<br>
>> simply have to forget the Pascal-style of passing return parameter=
s<br>
>> in. IMO it goes so much against the whole C++ philosophy and style=
..<br>
>> OTOH I can't think of one single std. library component doing =
that.<br>
>> Please do not get me wrong. I am not judging/criticizing your<br>
>> programming style and personal preferences. Only saying that IMO t=
hat<br>
>> choice will push so many people away (for practical, stylistic, et=
c.<br>
>> reasons) even before we get into a serious discussion.<br>
>><br>
>> Just my 2c.<br>
>> V.<br>
>><br>
>><br>
>><br>
>> On Sat, Feb 1, 2014 at 9:54 AM, Bengt Gustafsson<br>
>> <<a href=3D"mailto:bengt.gustafsson@beamways.com">bengt.gustafs=
son@beamways.com</a>> wrote:<br>
>> > I think it must be easy to do easy things. My first choice wo=
uld still<br>
>> > be to<br>
>> > have the destination as a reference parameter as you don'=
t have to mess<br>
>> > with<br>
>> > the explicit template type and match it to the variable. This=
basically<br>
>> > leaves my original error_return class. This allows checking t=
he return<br>
>> > value<br>
>> > with a surrounding if.<br>
>> ><br>
>> > I can't see a way to actually return both the value and t=
he possible<br>
>> > error<br>
>> > code without using an extra named variable, although of cours=
e it can be<br>
>> > auto typed. Together with the explicit template parameter it =
builds<br>
>> > clumsiness:<br>
>> ><br>
>> > int x;<br>
>> > if (!FromString(x, "123"))<br>
>> > =C2=A0 =C2=A0 ... handle error without using error code;<br>
>> ><br>
>> > or<br>
>> > int x;<br>
>> > if (!auto err =3D FromString(x, "123")) =C2=A0 // T=
his relies on extended<br>
>> > if-initalizer functionality being suggested!<br>
>> > =C2=A0 =C2=A0 ... handle error using error code available fro=
m err which I guess<br>
>> > is<br>
>> > basically an exception_ptr;<br>
>> ><br>
>> ><br>
>> ><br>
>> > vs.<br>
>> ><br>
>> > int x;<br>
>> > auto tmp =3D FromString<int>("123");<br>
>> > if (tmp)<br>
>> > =C2=A0 =C2=A0 x =3D tmp.value();<br>
>> ><br>
>> > else<br>
>> > =C2=A0 =C2=A0 ... handle error using tmp.get_error() or somet=
hing like that.<br>
>> ><br>
>> ><br>
>> > Well, in the case that you need to get at the specific error =
code the<br>
>> > difference in clumsiness is maybe not that great. However ple=
ase note<br>
>> > that<br>
>> > my destructor exception gets thrown even if the first convers=
ion didn't<br>
>> > fail, the throw is just caused by the non-checking of the res=
ult, which<br>
>> > the<br>
>> > alternative code using value() which throws if the conversion=
went south<br>
>> > does not provide.<br>
>> ><br>
>> > As the previous speaker I'm however leaning towards wishi=
ng for a<br>
>> > language<br>
>> > feature that can deliver this as a compile time error. This e=
ither<br>
>> > requires<br>
>> > a very specific language feature for just this case (unlikely=
to happen)<br>
>> > or<br>
>> > maybe we could figure out some constexpr on steroids which ca=
n feed into<br>
>> > a<br>
>> > static_assert? Something like being to able to return a pair =
where one<br>
>> > of<br>
>> > the two is constexpr and the other not. The constexpr member =
must of<br>
>> > course<br>
>> > be evaluated at compile time and thus triggers the static_ass=
ert as<br>
>> > needed.<br>
>> > I'm not fully up to speed with the newest constexpr stuff=
like constexpr<br>
>> > constructors, maybe this is already doable? A sketch:<br>
>> ><br>
>> > template<typename T> struct static_check_ret {<br>
>> > =C2=A0 =C2=A0 T retval;<br>
>> ><br>
>> > =C2=A0 =C2=A0 ~static_check_ret() { static_assert(checked, &q=
uot;Return code never<br>
>> > checked"); }<br>
>> > =C2=A0 =C2=A0 operator bool () { checked =3D true; }<br>
>> > =C2=A0 =C2=A0 T value_or(const T& other) { checked =3D tr=
ue; }<br>
>> > =C2=A0 =C2=A0 mutable constexpr bool checked =3D false; =C2=
=A0// But now this one is only<br>
>> > a<br>
>> > little constexpr! The initialization sets it false but then i=
t can be<br>
>> > set<br>
>> > true when the COMPILER sees use of the methods that sets it t=
rue!<br>
>> > }<br>
>> > If anyone sees this as valuable (I seriously doubt that) the =
variable<br>
>> > could<br>
>> > possibly be declared mutable constexpr to allow this type of =
compile<br>
>> > time<br>
>> > magic.<br>
>> > The great thing would of course be that we could make sure th=
e return<br>
>> > code<br>
>> > is checked at all callsites (or ignored of course) without in=
curring<br>
>> > runtime<br>
>> > overhead. The limitations of what needs to be inline for the =
compiler to<br>
>> > be<br>
>> > able to do this does not look appealing though. Also of cours=
e the<br>
>> > assignments to a mutable constexpr must be to constexpr data =
and not<br>
>> > inside<br>
>> > some non-constexpr condition. Note that of course the entire =
operator<br>
>> > bool()<br>
>> > and value_or() are not constexpr!<br>
>> ><br>
>> > Can anyone come up with additional use cases for such a const=
ruct? Is it<br>
>> > even worth contemplating? Still better than a special solutio=
n for just<br>
>> > the<br>
>> > return value checking enforcement case, in my mind. It looks =
that it<br>
>> > could<br>
>> > have some use in general in template metaprogramming.<br>
>> ><br>
>> > Having written this it seems quite apparent that this is a re=
ally scary<br>
>> > little feature to standardize and for compiler vendors to imp=
lement... I<br>
>> > just post this message as someone else may find more prominen=
t use cases<br>
>> > that could motivate the standardization and implementation ef=
fort.<br>
>> > Another<br>
>> > hope I have is that someone could find a way out to implement=
this with<br>
>> > today's definition of constexpr (we're now in 2014 af=
ter all...), which<br>
>> > would be great.<br>
>> ><br>
>> ><br>
>> > Den fredagen den 31:e januari 2014 kl. 12:02:25 UTC+1 skrev V=
ladimir<br>
>> > Batov:<br>
>> >><br>
>> >> Vicente et al,<br>
>> >><br>
>> >> Thanks for the info and the links. Much appreciated. The =
concept/idea<br>
>> >> and<br>
>> >> A. Alexandresku presentation look quite interesting as IM=
O it'd be<br>
>> >> quite<br>
>> >> applicable in string-to-T conversions that I myself was s=
omewhat<br>
>> >> interested/involved in. Not sure how it pans out in pract=
ice. I suspect<br>
>> >> generic implementation might be difficult to achieve. Wil=
l watch the<br>
>> >> space<br>
>> >> for more documentation/info. =C2=A0A website or a list th=
at I should be<br>
>> >> watching/monitoring for updates?<br>
>> >><br>
>> >> Thanks,<br>
>> >> V.<br>
>> >><br>
>> >> On Wednesday, January 29, 2014 5:41:18 AM UTC+11, Vicente=
J. Botet<br>
>> >> Escriba<br>
>> >> wrote:<br>
>> >>><br>
>> >>> Le 28/01/14 12:47, Klaim - Jo=C3=ABl Lamotte a =C3=A9=
crit :<br>
>> >>><br>
>> >>><br>
>> >>> On Tue, Jan 28, 2014 at 2:59 AM, Vladimir Batov <<=
a href=3D"mailto:vb.ma...@gmail.com">vb.ma...@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> Tried getting more info about Boost.Expected foll=
owing the links<br>
>> >>>> provided. Did not get far. Is there any documenta=
tion/discussion on<br>
>> >>>> the<br>
>> >>>> topic? Boost list maybe?<br>
>> >>><br>
>> >>><br>
>> >>> In case that helps:<br>
>> >>> The first time I heard about Expected it was in this =
presentation from<br>
>> >>> Alexandrescu, the first part (there are 3 parts), whi=
ch exposes the<br>
>> >>> rational<br>
>> >>> of such type:<br>
>> >>><br>
>> >>><br>
>> >>> <a href=3D"http://channel9.msdn.com/Shows/Going+Deep/=
C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C" targe=
t=3D"_blank">http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-An=
drei-Alexandrescu-Systematic-Error-Handling-in-C</a><br>
>> >>><br>
>> >>> I believe the Boost.Expected implementation is not ex=
actly similar but<br>
>> >>> share the same base.<br>
>> >>><br>
>> >>> Yes, Boost.Expected started based on the presentation=
from<br>
>> >>> Alexandrescu.<br>
>> >>> It has been extended and redesigned to take care of s=
ome features<br>
>> >>> found on<br>
>> >>> the future proposals and in the Haskell Monads.<br>
>> >>><br>
>> >>> The proposal is not yet ready because we want to inte=
grate better the<br>
>> >>> Monads concept.<br>
>> >>><br>
>> >>> Best,<br>
>> >>> Vicente<br>
>> ><br>
>> > --<br>
>> ><br>
>> > ---<br>
>> > You received this message because you are subscribed to a top=
ic in the<br>
>> > Google Groups "ISO C++ Standard - Future Proposals"=
group.<br>
>> > To unsubscribe from this topic, visit<br>
>> ><br>
>> > <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std=
-proposals/260PWIq_7u0/unsubscribe" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/unsubscribe</a>.<br>
>> > To unsubscribe from this group and all its topics, send an em=
ail to<br>
>> > <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
>> > To post to this group, send email to <a href=3D"mailto:std-pr=
oposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> > Visit this group at<br>
>> > <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pr=
oposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std=
-proposals/</a>.<br>
>><br>
>> --<br>
>><br>
>> ---<br>
>> You received this message because you are subscribed to the Google=
Groups<br>
>> "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an<br>
>> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> Visit this group at<br>
>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
><br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to a topic in the=
<br>
> Google Groups "ISO C++ Standard - Future Proposals" group.<b=
r>
> To unsubscribe from this topic, visit<br>
> <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/260PWIq_7u0/unsubscribe" target=3D"_blank">https://groups.google.com/a/is=
ocpp.org/d/topic/std-proposals/260PWIq_7u0/unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to<br=
>
> <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposal=
s+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5d2ea4dab07304f14fec78--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 01 Feb 2014 06:34:19 +0100
Raw View
This is a multi-part message in MIME format.
--------------010802090909090407070902
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/02/14 04:21, Matthew Fioravante a =C3=A9crit :
>
> On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R. wrote:
>
> Maybe you are looking for the support given in the header
> <system_error> from the error handling library.
>
>
> Perhaps, but in many cases I like to specify my own set of error=20
> codes. Using an enum is even better because you have the compiler help=20
> you ensure you handle them all with -Wswitch.
>
>
expected<T, myEnum> could be used in these cases.
>
>
> On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa wrote:
>
> ...
> The above isn't exactly what we had. The above is slightly more
> like an exception allowing any type to be stored in the error. We
> only permitted storing our base complex error type (similar to
> std::system_error in some regards but avoided any heap allocation
> and had a bunch of features irrelevant to this discussion). But it
> gives the general gist of how it could be used in a more generic
> setting as an alternative to exceptions. It obviously doesn't
> solve issues arising from avoiding using exceptions in
> constructors and overloaded operators though.
>
>
> I like your idea. A thread-local error state such as errno is not so=20
> evil as people make it out to be. As you say it certainly makes the=20
> stack propagation (aka the football part) easier. There was a lot of=20
> backlash against the errno pattern in the string-to-int thread. One=20
> thing I'd be curious about is what updating thread local state means=20
> for inlining. What kind of optimization is inhibited? The compiler can=20
> easily optimize out an unused return value but for a=20
> global/thread-local, it has no idea what the side effects could be.
I guess everyone agree here.
>
>
> OTOH I can't think of one single std. library component doing that.
> Please do not get me wrong. I am not judging/criticizing your
> programming style and personal preferences. Only saying that IMO that
> choice will push so many people away (for practical, stylistic, etc.
> reasons) even before we get into a serious discussion.
>
> Just my 2c.
> V.
>
>
> I like reference out parameters for the same reasons as the previous=20
> poster. They work very well for precedural interfaces with overloading.
>
> int val;
> if(!fromString("1234", val)) {
> //handle error
> }
>
We are not discussing here only about a fromString function but about a=20
generic retcode class. The user can define both with expected
expected<void, error_code> from_string(std::string, T&);
expected<T, error_code> from_string(std::string);
Both are useful and each one has its advantages and liabilities. But=20
both make use of the same generic expect class.
Whether the expected destructor must terminate if the error_code has not=20
been inspected is subject to discussion. We could as well have two=20
classes, one that lets the user the responsability to do whatever she=20
wants and don't need to track if the error_code/exception has been=20
inspected and one one wrapper that request for inspection.
inspect_guard<expected<void, error_code>> from_string(std::string, T);
inspect_guard<expected<T, error_code>> from_string(std::string);
or an alias template
using expected_guard =3D inspect_guard<expected<T, E>>;
> The above does the conversion and checks for errors in one line of=20
> code. It takes advantage of overloading. Its also in my opinion very=20
> elegant and simple.
The major issue with (in/)out parameters is that the procedures don't=20
compose/scale well.
With out parameters (either with retcode or expected<void, error_code>)
expected<void, error_code> from_string(std::string, T);
you must do
int val;
if(!fromString("1234", val)) {
//handle error
}
another_function(val);
With
expected<T, error_code> from_string(std::string);
you can just do
another_function(from_string<int>("1234"));
as far as another_function has an overload with expected as parameter.
Otherwise you could do
return from_string<int>("1234").then([](auto val){ return=20
another_function(val);});
If we reach to include in the standard an await/expect operator, the=20
following
another_function(*await* from_string<int>("1234"));
could be equivalent to
*auto tmp =3D *from_string<int>("1234");
*if (!tmp) return tmp.get_exceptional();*
another_function(*tmp.get()*);
>
> These are redundant and require either exceptions or reusing a valid=20
> int value to denote errors. The first requires special care if we=20
> change the type of val. Imagine changing val to long. The code still=20
> compiles just fine. The second version avoids the potential bug of=20
> changing the type of val but is verbose.
> int val =3D fromString<int>("1234");
> int val =3D fromString<decltype(val)>("1234"):
>
or
auto val =3D fromString<int>("1234");
> These still use out parameters but require more code:
> int val =3D fromString<int>("1234", was_successful);
> if(was_successful) {
> }
>
Agreed.
auto val =3D fromString<int>("1234");
if(val) {
}
> The only major disadvantage to reference out parameters as mentioned=20
> in the other thread is that you can't initialize things.
I would add a second only major disadvantage, functions with out=20
parameters do not compose as described above.
>
> For class types, the reference out parameter really doesn't work so=20
> well. Sometimes you really need to use the constructor instead of=20
> default constructing and then assigning later. That is not the case=20
> here as we are talking about assigning to simple ints and floats.
This post is about a retcode class, independently of a fromString=20
function, isn't it? I would prefer a generic solution that takes care of=20
both cases.
>
> For const, there are some workarounds. For example if you are parsing=20
> a lot of ints, you can use one variable to parse into. I'll admit this=20
> is a little less ideal (one extra variable in the scope, eww!).
>
> int val;
> if(!fromString("1234",val)) {
> }
> const int x =3D val;
> if(!fromString("56",val)) {
> }
> const int y =3D val;
> if(!fromString("78",val)) {
> }
> int z =3D val;
>
> As for the new ideas of std::optional, and expected, I haven't quite=20
> come to an solid opinion on those yet. It does require a bit more code=20
> to unpack the errors and return values out of those.
>
Could you elaborate here?
> Remember this discussion is about C like procedural interfaces where=20
> the costs of exceptions is high so we have to fallback on return=20
> values and/or out parameters. Like we used to call some C++=20
> programming style "C with classes", think of this as "C with=20
> templates, overloading, and possibly constexpr"
>
As I understand it, expected<T,your_error_code> should not imply an=20
exception cost as this is exactly its purpose
Best,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------010802090909090407070902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/02/14 04:21, Matthew Fioravante a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R. wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div dir=3D"ltr">Maybe you are looking for the support given in
the header <system_error> from the error handling
library.</div>
</blockquote>
<div><br>
</div>
<div>Perhaps, but in many cases I like to specify my own set of
error codes. Using an enum is even better because you have the
compiler help you ensure you handle them all with -Wswitch.=C2=A0=
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
expected<T, myEnum> could be used in these cases.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div dir=3D"ltr">
<div>...</div>
<div>The above isn't exactly what we had. The above is
slightly more like an exception allowing any type to be
stored in the error. We only permitted storing our base
complex error type (similar to std::system_error in some
regards but avoided any heap allocation and had a bunch
of features irrelevant to this discussion). But it gives
the general gist of how it could be used in a more
generic setting as an alternative to exceptions. It
obviously doesn't solve issues arising from avoiding
using exceptions in constructors and overloaded
operators though.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I like your idea. A thread-local error state such as
errno is not so evil as people make it out to be. As you say
it certainly makes the stack propagation (aka the football
part) easier. There was a lot of backlash against the errno
pattern in the string-to-int thread. One thing I'd be
curious about is what updating thread local state means for
inlining. What kind of optimization is inhibited? The
compiler can easily optimize out an unused return value but
for a global/thread-local, it has no idea what the side
effects could be.</div>
</div>
</div>
</blockquote>
I guess everyone agree here.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<br>
<div>=C2=A0
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">OTOH
I can't think of one single std. library component doing
that.=C2=A0<br>
Please do not get me wrong. I am not judging/criticizing
your=C2=A0<br>
programming style and personal preferences. Only saying
that IMO that=C2=A0<br>
choice will push so many people away (for practical,
stylistic, etc.=C2=A0<br>
reasons) even before we get into a serious discussion.=C2=A0<=
br>
<br>
Just my 2c.=C2=A0<br>
V.=C2=A0<br>
</blockquote>
</div>
<div><br>
</div>
<div>I like reference out parameters for the same reasons as
the previous poster. They work very well for precedural
interfaces with overloading.</div>
<div><br>
</div>
<div>int val;</div>
<div>if(!fromString("1234", val)) {<br>
=C2=A0 //handle error</div>
<div>}</div>
<div><br>
</div>
</div>
</div>
</blockquote>
We are not discussing here only about a fromString function but
about a generic retcode class. The user can define both with
expected<br>
<br>
expected<void, error_code> from_string(std::string, T&);<br>
expected<T, error_code> from_string(std::string);<br>
<br>
<br>
Both are useful and each one has its advantages and liabilities. But
both make use of the same generic expect class.<br>
<br>
Whether the expected destructor must terminate if the error_code has
not been inspected is subject to discussion. We could as well have
two classes, one that lets the user the responsability to do
whatever she wants and don't need to track if the
error_code/exception has been inspected and one one wrapper that
request for inspection. <br>
<br>
inspect_guard<expected<void, error_code>>
from_string(std::string, T);<br>
inspect_guard<expected<T, error_code>>
from_string(std::string);<br>
<br>
or an alias template<br>
<br>
using expected_guard =3D inspect_guard<expected<T, E>>;
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>The above does the conversion and checks for errors in
one line of code. It takes advantage of overloading. Its
also in my opinion very elegant and simple.</div>
</div>
</div>
</blockquote>
The major issue with (in/)out parameters is that the procedures
don't compose/scale well.<br>
<br>
With out parameters (either with retcode or expected<void,
error_code>)<br>
<br>
expected<void, error_code> from_string(std::string, T);<br>
<br>
you must do <br>
<br>
<div>int val;</div>
<div>if(!fromString("1234", val)) {<br>
=C2=A0 //handle error</div>
<div>}</div>
another_function(val);<br>
<br>
With<br>
<br>
expected<T, error_code> from_string(std::string);<br>
<br>
you can just do <br>
<br>
another_function(from_string<int>("1234"));<br>
<br>
as far as another_function has an overload with expected as
parameter.<br>
<br>
Otherwise you could do<br>
<br>
return from_string<int>("1234").then([](auto val){ return
another_function(val);});<br>
<br>
If we reach to include in the standard an await/expect operator, the
following <br>
<br>
another_function(<b>await</b> from_string<int>("1234"));<br>
<br>
could be equivalent to <br>
<br>
<b>auto tmp =3D </b>from_string<int>("1234");<br>
<b>if (!tmp) return tmp.get_exceptional();</b><br>
another_function(<b>tmp.get()</b>);<br>
<br>
<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<div>These are redundant and require either exceptions or
reusing a valid int value to denote errors. The first
requires special care if we change the type of val. Imagine
changing val to long. The code still compiles just fine. The
second version avoids the potential bug of changing the type
of val but is verbose.</div>
<div>int val =3D fromString<int>("1234");</div>
<div>int val =3D fromString<decltype(val)>("1234"):</div>
<div><br>
</div>
</div>
</div>
</blockquote>
or<br>
<div>auto val =3D fromString<int>("1234");</div>
=C2=A0
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>These still use out parameters but require more code:</div>
<div>int val =3D fromString<int>("1234", was_successful);</=
div>
<div>if(was_successful) {<br>
}</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Agreed.<br>
<br>
<div>auto val =3D fromString<int>("1234");</div>
if(val) {<br>
<div>}</div>
<div><br>
</div>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>The only major disadvantage to reference out parameters
as mentioned in the other thread is that you can't
initialize things. <br>
</div>
</div>
</div>
</blockquote>
I would add a second only major disadvantage, functions with out
parameters do not compose as described above.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>For class types, the reference out parameter really doesn't
work so well. Sometimes you really need to use the constructor
instead of default constructing and then assigning later. That
is not the case here as we are talking about assigning to
simple ints and floats.</div>
</div>
</blockquote>
This post is about a retcode class, independently of a fromString
function, isn't it? I would prefer a generic solution that takes
care of both cases.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>For const, there are some workarounds. For example if you
are parsing a lot of ints, you can use one variable to parse
into. I'll admit this is a little less ideal (one extra
variable in the scope, eww!).</div>
<div><br>
</div>
<div>int val;</div>
<div>if(!fromString("1234",val)) {<br>
}</div>
<div>const int x =3D val;</div>
<div>
<div>if(!fromString("56",val)) {<br>
}</div>
<div>const int y =3D val;</div>
</div>
<div>
<div>if(!fromString("78",val)) {<br>
}</div>
<div>int z =3D val;</div>
</div>
<div><br>
</div>
<div>As for the new ideas of std::optional, and expected, I
haven't quite come to an solid opinion on those yet. It does
require a bit more code to unpack the errors and return values
out of those.</div>
<div><br>
</div>
</div>
</blockquote>
Could you elaborate here?<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>Remember this discussion is about C like procedural
interfaces where the costs of exceptions is high so we have to
fallback on return values and/or out parameters. Like we used
to call some C++ programming style "C with classes", think of
this as "C with templates, overloading, and possibly
constexpr"</div>
</div>
<br>
</blockquote>
As I understand it, expected<T,your_error_code> should not
imply an exception cost as this is exactly its purpose<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010802090909090407070902--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Fri, 31 Jan 2014 21:39:08 -0800 (PST)
Raw View
------=_Part_2635_309820.1391233148375
Content-Type: text/plain; charset=UTF-8
On Saturday, February 1, 2014 2:21:40 PM UTC+11, Matthew Fioravante wrote:
>
>
> On Friday, January 31, 2014 6:09:39 PM UTC-5, Vladimir Batov wrote:
>>
>> > ... the destination as a reference parameter...
>>
>> My *very personal* view is that, if you want your proposal to be
>> seriously considered by wide C++ community and to get anywhere, you
>> simply have to forget the Pascal-style of passing return parameters
>> in. IMO it goes so much against the whole C++ philosophy and style.
>>
>
> C++ philosophy? Says who?
>
"... functions that modify call-by-reference arguments can make programs
hard to read and should most often be avoided..." 7.2 The C++ Programming
Language by B. Stroustrup. Ignorance is a bliss.
> I don't give a damn about past precedents.
>
Yes, that's a mature response showing the spirit of cooperation and team
work and valuing your customer base.
> All other things being equal, convention should be followed. All other
> things being very unequal, convention should be abandoned in favor of
> superior tools and interfaces. Many things that used to be considered good
> practice and style are now laughable.
>
Laughable?.. No less?.. I might say "Says who?"
> We should always keep our minds open and design the best tools.
Oh, boy. Saw something I thought was interesting. Come here hoping to learn
more and maybe to have a serious technical conversation. Ended up with
someone I've never heard before giving me a lecture what to *always* do
with my mind. I thought it was an ISO C++ forum. :-(
>
>> OTOH I can't think of one single std. library component doing that.
>> Please do not get me wrong. I am not judging/criticizing your
>> programming style and personal preferences. Only saying that IMO that
>> choice will push so many people away (for practical, stylistic, etc.
>> reasons) even before we get into a serious discussion.
>>
>
> I like reference out parameters for the same reasons as the previous
> poster. They work very well for precedural interfaces with overloading.
>
Honestly, I write "OTOH I can't think of one single std. library component
doing that" and you reply "I like it". Really?! I don't give a hoot what
*you* like. The discussion was not about you. Given it's an ISO C++ forum
people would be discussing widely applicable, widely acceptable, generic
components potentially good for standardization... or so I thought. Anyway,
I was not and I am not picking a fight. Let's consider this particular
conversation closed.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2635_309820.1391233148375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Saturday, February 1, 2014 2:21:40 PM UTC+11, Matth=
ew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br><div>On Friday, January 31, 2014 6:09:39 PM UTC-5, Vladim=
ir Batov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">> ... the destination as a reference par=
ameter... <br><br>My *very personal* view is that, if you want your pr=
oposal to be <br>seriously considered by wide C++ community and to get=
anywhere, you <br>simply have to forget the Pascal-style of passing r=
eturn parameters <br>in. IMO it goes so much against the whole C++ phi=
losophy and style. <br></blockquote><div><br></div><div>C++ philosophy=
? Says who? </div></div></div></div></blockquote><div><br>"... functions th=
at modify call-by-reference arguments can make programs hard to read and sh=
ould most often be avoided..." 7.2 The C++ Programming Language by B. Strou=
strup. Ignorance is a bliss.<br> </div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div><div>I don't give a damn about pas=
t precedents. </div></div></div></div></blockquote><div><br>Yes, that's a m=
ature response showing the spirit of cooperation and team work and valuing =
your customer base. <br> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div><div>All other things being equal, convent=
ion should be followed. All other things being very unequal, convention sho=
uld be abandoned in favor of superior tools and interfaces. Many things tha=
t used to be considered good practice and style are now laughable. </div></=
div></div></div></blockquote><div><br>Laughable?.. No less?.. I might say "=
Says who?"<br><br>> We should always keep our minds open and design the =
best tools.</div><div><br>Oh, boy. Saw something I thought was interesting.=
Come here hoping to learn more and maybe to have a serious technical conve=
rsation. Ended up with someone I've never heard before giving me a lecture =
what to *always* do with my mind. I thought it was an ISO C++ forum. :-(<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">OTOH I can't think of one single =
std. library component doing that. <br>Please do not get me wrong. I a=
m not judging/criticizing your <br>programming style and personal pref=
erences. Only saying that IMO that <br>choice will push so many people=
away (for practical, stylistic, etc. <br>reasons) even before we get =
into a serious discussion. <br></blockquote></div><div><br></div><div>I lik=
e reference out parameters for the same reasons as the previous poster. The=
y work very well for precedural interfaces with overloading.</div></div></d=
iv></blockquote><br>Honestly, I write "OTOH I can't think of one single std=
.. library component doing that" and you reply "I like it". Really?! I don't=
give a hoot what *you* like. The discussion was not about you. Given it's =
an ISO C++ forum people would be discussing widely applicable, widely accep=
table, generic components potentially good for standardization... or so I t=
hought. Anyway, I was not and I am not picking a fight. Let's consider this=
particular conversation closed. <br><br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2635_309820.1391233148375--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Fri, 31 Jan 2014 22:34:36 -0800
Raw View
--047d7b5d49ce59201904f1527efc
Content-Type: text/plain; charset=UTF-8
This really goes back to the formatting question. We are in a position
where nobody is completely happy with any of the options.
* Throwing exceptions is expensive, extremely verbose, and problematic in
many scenarios where code was not written with exception safety in mind
* Returning error codes is error prone in that users can forget to check
them. Plus, it can cause confusion for callers because parameters are
usually used for input, not output.
* Thread-local error codes also impose expense, and are even more likely to
be unchecked by users, but avoid needing to use a parameter for output.
* Returning an Expected or similar object makes unpacking the value
relatively opaque (e.g. encouraging assignments in conditionals), and
relies on a feature whose future impact on maintainability is unknown.
Arguing about which one is the best to use will never end, because there
are contrived scenarios that might cause someone to choose each model.
Personally, I would probably argue for returning
>>I don't give a damn about past precedents.
>Yes, that's a mature response showing the spirit of cooperation and team
work and valuing your customer base.
Vicente has a point here in that C++ already comes with two formatting / IO
libraries, both of which are almost universally considered poor / mediocre
at best, even by fans of the language. cstdio is limited by a C API, is
memory unsafe, provides no redirection or localization support out of the
box, and is hampered with memory corruption headaches which have resulted
in thousands of security vulnerabilities. iostreams are poor performing,
complicated and difficult to extend, don't achieve localization goals very
well, and are difficult to teach to beginners given their reliance on
operator overloading for basic IO. Precedent for being in the standard
library already isn't much of an argument here.
Vladimir has a point here in that we can't just cast precedent by the
wayside. One of the reasons many other languages' stream libraries have
been better received than C++'s is that C++ blazed that path, and future
language and standard library developers (e.g. in Java, C#, Python, etc.)
One option here is to look at what worked in other languages. Before
something goes into the standard, there should be precedent showing that a
feature is useful in real programs; Boost has been contributing libraries
for just this purpose for years. I suspect any proposed IO replacement
would need to start in Boost first; though I'm not on the committee :).
> My *very personal* view is that, if you want your proposal to
be seriously considered by wide C++ community and to get anywhere,
you simply have to forget the Pascal-style of passing return parameters in.
We should not make technical decisions about what interface best meets the
scenarios for which a library is designed based on what's "popular." If out
parameters result in the most maintainable code in real programs, then out
parameters need to be discussed, regardless of people's "opinions." This
can only come from growing a library into the role.
> I like reference out parameters for the same reasons as the previous
poster.
Ditto. What one person or another "likes" is irrelevant, because we can
find lots of people that like any of the above solutions.
> OTOH I can't think of one single std. library component doing that
std::getline does this. And this is one of the parts of iostreams that do
work well; e.g. both Andrei Alexandrescu and Stephan T. Lavavej discussed
good reasons for that design in Andrei's Going Native 2013
<http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly>talk
(jump to approximately 50 minutes in). None of those good reasons apply for
built in types like ints though.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Fri, Jan 31, 2014 at 9:39 PM, Vladimir Batov <vb.mail.247@gmail.com>wrote:
>
> On Saturday, February 1, 2014 2:21:40 PM UTC+11, Matthew Fioravante wrote:
>>
>>
>> On Friday, January 31, 2014 6:09:39 PM UTC-5, Vladimir Batov wrote:
>>>
>>> > ... the destination as a reference parameter...
>>>
>>> My *very personal* view is that, if you want your proposal to be
>>> seriously considered by wide C++ community and to get anywhere, you
>>> simply have to forget the Pascal-style of passing return parameters
>>> in. IMO it goes so much against the whole C++ philosophy and style.
>>>
>>
>> C++ philosophy? Says who?
>>
>
> "... functions that modify call-by-reference arguments can make programs
> hard to read and should most often be avoided..." 7.2 The C++ Programming
> Language by B. Stroustrup. Ignorance is a bliss.
>
>
>> I don't give a damn about past precedents.
>>
>
> Yes, that's a mature response showing the spirit of cooperation and team
> work and valuing your customer base.
>
>
>> All other things being equal, convention should be followed. All other
>> things being very unequal, convention should be abandoned in favor of
>> superior tools and interfaces. Many things that used to be considered good
>> practice and style are now laughable.
>>
>
> Laughable?.. No less?.. I might say "Says who?"
>
>
> > We should always keep our minds open and design the best tools.
>
> Oh, boy. Saw something I thought was interesting. Come here hoping to
> learn more and maybe to have a serious technical conversation. Ended up
> with someone I've never heard before giving me a lecture what to *always*
> do with my mind. I thought it was an ISO C++ forum. :-(
>
>
>>
>>> OTOH I can't think of one single std. library component doing that.
>>> Please do not get me wrong. I am not judging/criticizing your
>>> programming style and personal preferences. Only saying that IMO that
>>> choice will push so many people away (for practical, stylistic, etc.
>>> reasons) even before we get into a serious discussion.
>>>
>>
>> I like reference out parameters for the same reasons as the previous
>> poster. They work very well for precedural interfaces with overloading.
>>
>
> Honestly, I write "OTOH I can't think of one single std. library component
> doing that" and you reply "I like it". Really?! I don't give a hoot what
> *you* like. The discussion was not about you. Given it's an ISO C++ forum
> people would be discussing widely applicable, widely acceptable, generic
> components potentially good for standardization... or so I thought. Anyway,
> I was not and I am not picking a fight. Let's consider this particular
> conversation closed.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b5d49ce59201904f1527efc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This really goes back to the formatting question. We =
are in a position where nobody is completely happy with any of the options.=
</div><div><br></div><div>* Throwing exceptions is expensive, extremely ver=
bose, and problematic in many scenarios where code was not written with exc=
eption safety in mind</div>
<div>* Returning error codes is error prone in that users can forget to che=
ck them. Plus, it can cause confusion for callers because parameters are us=
ually used for input, not output.</div><div>* Thread-local error codes also=
impose expense, and are even more likely to be unchecked by users, but avo=
id needing to use a parameter for output.</div>
<div>* Returning an Expected or similar object makes unpacking the value re=
latively opaque (e.g. encouraging assignments in conditionals), and relies =
on a feature whose future impact on maintainability is unknown.</div><div>
<br></div><div>Arguing about which one is the best to use will never end, b=
ecause there are contrived scenarios that might cause someone to choose eac=
h model. Personally, I would probably argue for returning </div><div><br>
</div><div>>>I don't give a damn about past precedents. <br>>Y=
es, that's a mature response showing the spirit of cooperation and team=
work and valuing your customer base.</div><div><br></div><div>Vicente has =
a point here in that C++ already comes with two formatting / IO libraries, =
both of which are almost universally considered poor / mediocre at best, ev=
en by fans of the language. cstdio is limited by a C API, is memory unsafe,=
provides no redirection or localization support out of the box, and is ham=
pered with memory corruption headaches which have resulted in thousands of =
security vulnerabilities. iostreams are poor performing, complicated and di=
fficult to extend, don't achieve localization goals very well, and are =
difficult to teach to beginners given their reliance on operator overloadin=
g for basic IO. Precedent for being in the standard library already isn'=
;t much of an argument here.</div>
<div><br></div><div>Vladimir has a point here in that we can't just cas=
t precedent by the wayside. One of the reasons many other languages' st=
ream libraries have been better received than C++'s is that C++ blazed =
that path, and future language and standard library developers (e.g. in Jav=
a, C#, Python, etc.) One option here is to look at what worked in other lan=
guages. Before something goes into the standard, there should be precedent =
showing that a feature is useful in real programs; Boost has been contribut=
ing libraries for just this purpose for years. I suspect any proposed IO re=
placement would need to start in Boost first; though I'm not on the com=
mittee :).</div>
<div><br></div><div><div>> My *very personal* view is that, if you want =
your proposal to be=C2=A0seriously considered by wide C++ community and to =
get anywhere, you=C2=A0simply have to forget the Pascal-style of passing re=
turn parameters=C2=A0in.</div>
<div><br></div><div>We should not make technical decisions about what inter=
face best meets the scenarios for which a library is designed based on what=
's "popular." If out parameters result in the most maintainab=
le code in real programs, then out parameters need to be discussed, regardl=
ess of people's "opinions." This can only come from growing a=
library into the role.</div>
<div><br></div></div><div>> I like reference out parameters for the same=
reasons as the previous poster.</div><div><br></div><div>Ditto. What one p=
erson or another "likes" is irrelevant, because we can find lots =
of people that like any of the above solutions.</div>
<div><br></div><div>> OTOH I can't think of one single std. library =
component doing that</div><div><br></div><div>std::getline does this. And t=
his is one of the parts of iostreams that do work well; e.g. both Andrei Al=
exandrescu=C2=A0and Stephan T. Lavavej discussed good reasons for that desi=
gn in <a href=3D"http://channel9.msdn.com/Events/GoingNative/2013/Writing-Q=
uick-Code-in-Cpp-Quickly">Andrei's Going Native 2013 </a>talk (jump to =
approximately 50 minutes in). None of those good reasons apply for built in=
types like ints though.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Fri, Jan 31, 2014 at 9:39 PM, Vladimi=
r Batov <span dir=3D"ltr"><<a href=3D"mailto:vb.mail.247@gmail.com" targ=
et=3D"_blank">vb.mail.247@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><br>On Saturday, February 1, 2014 2:21:4=
0 PM UTC+11, Matthew Fioravante wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,2=
04,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><br><div>On Friday, January 31, 2014 6:09:39 PM UTC-5=
, Vladimir Batov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid">
> ... the destination as a reference parameter...=C2=A0<br><br>My *very =
personal* view is that, if you want your proposal to be=C2=A0<br>seriously =
considered by wide C++ community and to get anywhere, you=C2=A0<br>simply h=
ave to forget the Pascal-style of passing return parameters=C2=A0<br>
in. IMO it goes so much against the whole C++ philosophy and style.=C2=A0<b=
r></blockquote><div><br></div><div>C++ philosophy? Says who? </div></div></=
div></div></blockquote></div><div><br>"... functions that modify call-=
by-reference arguments can make programs hard to read and should most often=
be avoided..." 7.2 The C++ Programming Language by B. Stroustrup. Ign=
orance is a bliss.<br>
=C2=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div><=
div>I don't give a damn about past precedents. </div>
</div></div></div></blockquote></div><div><br>Yes, that's a mature resp=
onse showing the spirit of cooperation and team work and valuing your custo=
mer base. <br>=C2=A0</div><div class=3D"im"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div><div>All other things being equal, convention sh=
ould be followed. All other things being very unequal, convention should be=
abandoned in favor of superior tools and interfaces. Many things that used=
to be considered good practice and style are now laughable. </div>
</div></div></div></blockquote></div><div><br>Laughable?.. No less?.. I mig=
ht say "Says who?"<div class=3D"im"><br><br>> We should always=
keep our minds open and design the best tools.</div></div><div><br>Oh, boy=
.. Saw something I thought was interesting. Come here hoping to learn more a=
nd maybe to have a serious technical conversation. Ended up with someone I&=
#39;ve never heard before giving me a lecture what to *always* do with my m=
ind. I thought it was an ISO C++ forum. :-(<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid"><div dir=3D"ltr"><div><div class=3D"im"><div><di=
v>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">OTOH I can't think of one single std. library componen=
t doing that.=C2=A0<br>
Please do not get me wrong. I am not judging/criticizing your=C2=A0<br>prog=
ramming style and personal preferences. Only saying that IMO that=C2=A0<br>=
choice will push so many people away (for practical, stylistic, etc.=C2=A0<=
br>reasons) even before we get into a serious discussion. <br>
</blockquote></div><div><br></div></div><div class=3D"im"><div>I like refer=
ence out parameters for the same reasons as the previous poster. They work =
very well for precedural interfaces with overloading.</div></div></div></di=
v>
</blockquote><br>Honestly, I write "OTOH I can't think of one sing=
le std. library component doing that" and you reply "I like it&qu=
ot;. Really?! I don't give a hoot what *you* like. The discussion was n=
ot about you. Given it's an ISO C++ forum people would be discussing wi=
dely applicable, widely acceptable, generic components potentially good for=
standardization... or so I thought. Anyway, I was not and I am not picking=
a fight. Let's consider this particular conversation closed. <br>
<br><br></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5d49ce59201904f1527efc--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 1 Feb 2014 19:33:12 +1100
Raw View
On Sat, Feb 1, 2014 at 5:34 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> This really goes back to the formatting question. We are in a position where
> nobody is completely happy with any of the options.
Indeed. IMO in such a not-that-unusual :-( situation the authors need
to ultimately go ahead with what they consider the right way to move
forward. In my experience trying to satisfy everyone and their
neighbors results in design compromises and the outcome does not
please anyone, i.e. the project fails.
> * Throwing exceptions is expensive, extremely verbose, and problematic in
> many scenarios where code was not written with exception safety in mind
> * Returning error codes is error prone in that users can forget to check
> them. Plus, it can cause confusion for callers because parameters are
> usually used for input, not output.
> * Thread-local error codes also impose expense, and are even more likely to
> be unchecked by users, but avoid needing to use a parameter for output.
> * Returning an Expected or similar object makes unpacking the value
> relatively opaque (e.g. encouraging assignments in conditionals), and relies
> on a feature whose future impact on maintainability is unknown.
>
> Arguing about which one is the best to use will never end, because there are
> contrived scenarios that might cause someone to choose each model.
> Personally, I would probably argue for returning
My copy of your email simply says "I would probably argue for
returning..." but I assume you were referring to the last entry in
your list -- returning an instance of 'expected'. I personally heavily
lean towards it as well. In fact, that's the reason I am here. :-) So,
I'd personally very much like to see that design pursued.
>>>I don't give a damn about past precedents.
>>Yes, that's a mature response showing the spirit of cooperation and team
>> work and valuing your customer base.
>
> Vicente has a point here in that C++ already comes with two formatting / IO
> libraries, both of which are almost universally considered poor / mediocre
> at best, even by fans of the language. cstdio is limited by a C API, is
> memory unsafe, provides no redirection or localization support out of the
> box, and is hampered with memory corruption headaches which have resulted in
> thousands of security vulnerabilities. iostreams are poor performing,
> complicated and difficult to extend, don't achieve localization goals very
> well, and are difficult to teach to beginners given their reliance on
> operator overloading for basic IO. Precedent for being in the standard
> library already isn't much of an argument here.
Yes, indeed, it's a well-known fact that iostreams is not the best
amongst C++ std. libs. By now only probably lazy did not kick it. I do
not believe anyone in their right mind would advocate using the lib.
as an example or a precedent to follow. I certainly was not. If it
came across as such, my humble apologies.
As for cstdio, then I personally would not be that harsh on that lib.
Well, it's been my friend for 30 years so I am biased :-)... And it
does support localization via wchar_t and utf8 (I am rusty in that
area)... and memory corruption problem is exaggerated IMO... anyway, I
digressed.
> Vladimir has a point here in that we can't just cast precedent by the
> wayside. One of the reasons many other languages' stream libraries have been
> better received than C++'s is that C++ blazed that path,
Indeed. I remember when it was first introduced... with so much
excitement and expectations... overloading of op>>() and op<<()!
Cool!.. Not anymore.
> ... Boost has been contributing libraries for just this
> purpose for years. I suspect any proposed IO replacement would need to start
> in Boost first; though I'm not on the committee :).
Boost IMO is an excellent testing ground for anything new. Last time I
checked one did not need to be "on the committee" to contribute to
Boost. I am still trying to figure out why, for example, this
'expected' proposal-to-be is not being tried through Boost but here.
>...
> We should not make technical decisions about what interface best meets the
> scenarios for which a library is designed based on what's "popular."
Isn't it funny how the same thing can be called "popular" by one and
"tested and proven and widely accepted" by others. Both might be true
but how different are the impression and the weight and what have you.
> ...
> OTOH I can't think of one single std. library component doing that
>
> std::getline does this. And this is one of the parts of iostreams that do
> work well; e.g. both Andrei Alexandrescu and Stephan T. Lavavej discussed
> good reasons for that design in Andrei's Going Native 2013 talk (jump to
> approximately 50 minutes in). None of those good reasons apply for built in
> types like ints though.
Ah, indeed, that pesky std::getline. Anyway, I feel we digressed. If I
was inadvertently the cause of it, my apologies. As Vicente timely
pointed out 'expected' can be used regardless. So, we probably should
focus on the original point of the discussion -- the 'expected'...
unless I again mis-understood something.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sat, 1 Feb 2014 11:39:12 +0100
Raw View
2014-02-01 Billy O'Neal <billy.oneal@gmail.com>:
> Hmmmm... I stand slightly corrected. I was under the impression that Java's
> int parsing worked this way; but looking now it appears that it throws
> exceptions. C# has gone this route though:
>
> http://msdn.microsoft.com/en-us/library/f02979c7(v=vs.110).aspx
>
> and I've never heard anyone complain about it there. (In contrast, I've
> heard plenty of people complain about the interface that throws exceptions)
The way you would do an attemptive conversion to a number in Java is
by passing a ParsePosition object to a Numberformat.parse function,
http://docs.oracle.com/javase/6/docs/api/java/text/NumberFormat.html#parse%28java.lang.String,%20java.text.ParsePosition%29
By this means you get the information whether the conversion failed
and if so at which position within the string without involving
exceptions. This is quite useful in tolerant string interpretation
situations and is similar to the approach of the strtoX functions from
<stdlib.h>.
I have a lot of experience with the "Try-" approach based on my long
history of working with Delphi,
http://docwiki.embarcadero.com/Libraries/XE4/de/System.SysUtils.TryStrToInt
(and I'm pretty sure that the C# approach got influenced by them). The
problem that I often found here is that these functions don't give you
the slightest clue *why* the conversion failed, this is the reason why
I think that the "fail-position-retrieval" approach is typically more
useful in tolerant parsing situations.
- Daniel
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Philipp Maximilian Stephani <p.stephani2@gmail.com>
Date: Sat, 01 Feb 2014 11:24:01 +0000
Raw View
--001a11c320ec057b2904f15687cb
Content-Type: text/plain; charset=UTF-8
On Sat Feb 01 2014 at 07:35:18, Billy O'Neal <billy.oneal@gmail.com> wrote:
> * Returning error codes is error prone in that users can forget to check
> them.
>
Most compilers have an attribute to emit a warning when a result is unused.
This attribute could be standardized.
> Plus, it can cause confusion for callers because parameters are usually
> used for input, not output.
>
This can be mitigated to some extend by not using non-const reference
parameters. Using pointers makes the modification explicit by having
callers take the address. In similar vein, C# requires using the "ref" or
"out" keyword both for declaration and at the call site.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c320ec057b2904f15687cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br><div>On Sat Feb 01 2014 at 07:35:18, Billy O'Neal <<a href=
=3D"mailto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>> wrote:</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>* Returning error codes is error prone in that users =
can forget to check them. </div></div></blockquote><div><br></div><div>Most=
compilers have an attribute to emit a warning when a result is unused. Thi=
s attribute could be standardized.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Plus,=
it can cause confusion for callers because parameters are usually used for=
input, not output.<br>
</div></div></blockquote><div><br></div><div>This can be mitigated to some =
extend by not using non-const reference parameters. Using pointers makes th=
e modification explicit by having callers take the address. In similar vein=
, C# requires using the "ref" or "out" keyword both for=
declaration and at the call site.</div>
<div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c320ec057b2904f15687cb--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sat, 1 Feb 2014 22:36:07 +1100
Raw View
On Sat, Feb 1, 2014 at 7:33 PM, Vladimir Batov <vb.mail.247@gmail.com> wrote:
>
> Boost IMO is an excellent testing ground for anything new. Last time I
> checked one did not need to be "on the committee" to contribute to
> Boost. I am still trying to figure out why, for example, this
> 'expected' proposal-to-be is not being tried through Boost but here.
Oops. Just realized it's actually called Boost.Expected and clearly
prepared as a Boost proposal. Aplogies.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 1 Feb 2014 10:49:37 -0800 (PST)
Raw View
------=_Part_2835_25041818.1391280577344
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
My intention was not to be hostile or offend anyone. The point I'm trying=
=20
to make is that "because we have always done it that way" or "because X=20
said so" is not a good enough reason alone to decide for or against=20
something. Not being able to initialize const variables is a good counter=
=20
argument to out parameters. Not being able to compose functions that use=20
out parameters is another good one.=20
On Saturday, February 1, 2014 1:34:36 AM UTC-5, Billy O'Neal wrote:
>
> This really goes back to the formatting question. We are in a position=20
> where nobody is completely happy with any of the options.
>
> * Throwing exceptions is expensive, extremely verbose, and problematic in=
=20
> many scenarios where code was not written with exception safety in mind
> * Returning error codes is error prone in that users can forget to check=
=20
> them. Plus, it can cause confusion for callers because parameters are=20
> usually used for input, not output.
> * Thread-local error codes also impose expense, and are even more likely=
=20
> to be unchecked by users, but avoid needing to use a parameter for output=
..
> * Returning an Expected or similar object makes unpacking the value=20
> relatively opaque (e.g. encouraging assignments in conditionals), and=20
> relies on a feature whose future impact on maintainability is unknown.
>
> Arguing about which one is the best to use will never end, because there=
=20
> are contrived scenarios that might cause someone to choose each model.
>
I came out of this thread more confused and bewildered than when I entered!=
=20
Coming out of this discussion what could be a good paper is someone=20
discussing all of the different ways to handle "output" from functions with=
=20
their merits and drawbacks. Some of the techniques will lend themselves=20
very well to certain situations while others not so much.
std::getline does this. And this is one of the parts of iostreams that do=
=20
> work well; e.g. both Andrei Alexandrescu and Stephan T. Lavavej discussed=
=20
> good reasons for that design in Andrei's Going Native 2013 <http://channe=
l9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly>talk=
=20
> (jump to approximately 50 minutes in). None of those good reasons apply f=
or=20
> built in types like ints though.
That's one situation where out parameters are absolutely the best design.=
=20
When you have a container and need to repeatedly call the method over and=
=20
over again to replace the contents, returning the data simply cannot work=
=20
efficiently.
On Saturday, February 1, 2014 5:39:12 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> 2014-02-01 Billy O'Neal <billy...@gmail.com>:=20
> > Hmmmm... I stand slightly corrected. I was under the impression that=20
> Java's=20
> > int parsing worked this way; but looking now it appears that it throws=
=20
> > exceptions. C# has gone this route though:=20
> >=20
> > http://msdn.microsoft.com/en-us/library/f02979c7(v=3Dvs.110).aspx=20
> >=20
> > and I've never heard anyone complain about it there. (In contrast, I've=
=20
> > heard plenty of people complain about the interface that throws=20
> exceptions)=20
>
> The way you would do an attemptive conversion to a number in Java is=20
> by passing a ParsePosition object to a Numberformat.parse function,=20
>
>
> http://docs.oracle.com/javase/6/docs/api/java/text/NumberFormat.html#pars=
e%28java.lang.String,%20java.text.ParsePosition%29
> =20
>
> By this means you get the information whether the conversion failed=20
> and if so at which position within the string without involving=20
> exceptions. This is quite useful in tolerant string interpretation=20
> situations and is similar to the approach of the strtoX functions from=20
> <stdlib.h>.=20
>
> I have a lot of experience with the "Try-" approach based on my long=20
> history of working with Delphi,=20
>
> http://docwiki.embarcadero.com/Libraries/XE4/de/System.SysUtils.TryStrToI=
nt
> =20
>
> (and I'm pretty sure that the C# approach got influenced by them). The=20
> problem that I often found here is that these functions don't give you=20
> the slightest clue *why* the conversion failed, this is the reason why=20
> I think that the "fail-position-retrieval" approach is typically more=20
> useful in tolerant parsing situations.=20
>
> If you use an error_code class which has a set of error condition enum=20
tags built in (like some of the ideas from this thread) instead of a bool,=
=20
you can retrieve that information if you need it. You can also have an=20
additional out parameter which gives you the string position. With=20
overloads we can add and remove these levels of detail when they are needed=
..
=20
On Saturday, February 1, 2014 6:24:01 AM UTC-5, Philipp Stephani wrote:
>
>
>
> On Sat Feb 01 2014 at 07:35:18, Billy O'Neal <billy...@gmail.com> wrote:
>
>> * Returning error codes is error prone in that users can forget to check=
=20
>> them.
>>
>
> Most compilers have an attribute to emit a warning when a result is=20
> unused. This attribute could be standardized.
> =20
>
+1 for that idea
=20
> Plus, it can cause confusion for callers because parameters are usually=
=20
>> used for input, not output.
>>
>
> This can be mitigated to some extend by not using non-const reference=20
> parameters. Using pointers makes the modification explicit by having=20
> callers take the address. In similar vein, C# requires using the "ref" or=
=20
> "out" keyword both for declaration and at the call site.
>
>
This is another big question that I have not been able to resolve. I've=20
never quite bought into one side or the other. Some people just use=20
non-const references while others use pointers for the reasons you=20
mentioned above. I hate both of these approaches.=20
Pointers are also bad:
- Callers can pass nullptr
- Whenever I see pointers in code I start thinking about memory=20
management. Do I need to delete this pointer? Who owns it? Whats its=20
lifetime?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2835_25041818.1391280577344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"font-size: 13px;">My intention was not=
to be hostile or offend anyone. The point I'm trying to make is that "beca=
use we have always done it that way" or "because X said so" is not a good e=
nough reason alone to decide for or against something. Not being able to in=
itialize const variables is a good counter argument to out parameters. Not =
being able to compose functions that use out parameters is another good one=
.. </span><br></div><div><span style=3D"font-size: 13px;"><br></span></=
div><div>On Saturday, February 1, 2014 1:34:36 AM UTC-5, Billy O'Neal wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-styl=
e: solid; padding-left: 1ex;"><div dir=3D"ltr"><div>This really goes back t=
o the formatting question. We are in a position where nobody is completely =
happy with any of the options.</div><div><br></div><div>* Throwing exceptio=
ns is expensive, extremely verbose, and problematic in many scenarios where=
code was not written with exception safety in mind</div><div>* Returning e=
rror codes is error prone in that users can forget to check them. Plus, it =
can cause confusion for callers because parameters are usually used for inp=
ut, not output.</div><div>* Thread-local error codes also impose expense, a=
nd are even more likely to be unchecked by users, but avoid needing to use =
a parameter for output.</div><div>* Returning an Expected or similar object=
makes unpacking the value relatively opaque (e.g. encouraging assignments =
in conditionals), and relies on a feature whose future impact on maintainab=
ility is unknown.</div><div><br></div><div>Arguing about which one is the b=
est to use will never end, because there are contrived scenarios that might=
cause someone to choose each model.</div></div></blockquote><div><br></div=
><div>I came out of this thread more confused and bewildered than when I en=
tered! Coming out of this discussion what could be a good paper is someone =
discussing all of the different ways to handle "output" from functions with=
their merits and drawbacks. Some of the techniques will lend themselves ve=
ry well to certain situations while others not so much.</div></div><div><br=
></div><div><br class=3D"Apple-interchange-newline"><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bord=
er-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: =
1ex;">std::getline does this. And this is one of the parts of iostreams tha=
t do work well; e.g. both Andrei Alexandrescu and Stephan T. Lavavej d=
iscussed good reasons for that design in <a href=3D"http://channel9.ms=
dn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly" target=3D=
"_blank">Andrei's Going Native 2013 </a>talk (jump to approximately 50=
minutes in). None of those good reasons apply for built in types like ints=
though.</blockquote></div><div><br></div><div>That's one situation where o=
ut parameters are absolutely the best design. When you have a container and=
need to repeatedly call the method over and over again to replace the cont=
ents, returning the data simply cannot work efficiently.</div><div><br></di=
v><div><br>On Saturday, February 1, 2014 5:39:12 AM UTC-5, Daniel Kr=C3=BCg=
ler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-=
left-style: solid; padding-left: 1ex;">2014-02-01 Billy O'Neal <<a targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"hSSGahPs5ssJ" style=3D"color: rgb(102=
, 17, 204);">billy...@gmail.com</a>>: <br>> Hmmmm... I stand sli=
ghtly corrected. I was under the impression that Java's <br>> int p=
arsing worked this way; but looking now it appears that it throws <br>=
> exceptions. C# has gone this route though: <br>> <br>>=
<a href=3D"http://msdn.microsoft.com/en-us/library/f02979c7(v=3Dvs.11=
0).aspx" target=3D"_blank">http://msdn.microsoft.com/en-<wbr>us/library/f02=
979c7(v=3Dvs.110).<wbr>aspx</a> <br>> <br>> and I've never =
heard anyone complain about it there. (In contrast, I've <br>> hear=
d plenty of people complain about the interface that throws exceptions)&nbs=
p;<br><br>The way you would do an attemptive conversion to a number in Java=
is <br>by passing a ParsePosition object to a Numberformat.parse func=
tion, <br><br><a href=3D"http://docs.oracle.com/javase/6/docs/api/java=
/text/NumberFormat.html#parse%28java.lang.String,%20java.text.ParsePosition=
%29" target=3D"_blank">http://docs.oracle.com/javase/<wbr>6/docs/api/java/t=
ext/<wbr>NumberFormat.html#parse%<wbr>28java.lang.String,%20java.<wbr>text.=
ParsePosition%29</a> <br><br>By this means you get the information whe=
ther the conversion failed <br>and if so at which position within the =
string without involving <br>exceptions. This is quite useful in toler=
ant string interpretation <br>situations and is similar to the approac=
h of the strtoX functions from <br><stdlib.h>. <br><br>I ha=
ve a lot of experience with the "Try-" approach based on my long <br>h=
istory of working with Delphi, <br><br><a href=3D"http://docwiki.embar=
cadero.com/Libraries/XE4/de/System.SysUtils.TryStrToInt" target=3D"_blank">=
http://docwiki.embarcadero.<wbr>com/Libraries/XE4/de/System.<wbr>SysUtils.T=
ryStrToInt</a> <br><br>(and I'm pretty sure that the C# approach got i=
nfluenced by them). The <br>problem that I often found here is that th=
ese functions don't give you <br>the slightest clue *why* the conversi=
on failed, this is the reason why <br>I think that the "fail-position-=
retrieval" approach is typically more <br>useful in tolerant parsing s=
ituations. <br><br></blockquote><div>If you use an error_code class wh=
ich has a set of error condition enum tags built in (like some of the ideas=
from this thread) instead of a bool, you can retrieve that information if =
you need it. You can also have an additional out parameter which gives you =
the string position. With overloads we can add and remove these levels of d=
etail when they are needed.</div><div> </div></div><div><br>On Saturda=
y, February 1, 2014 6:24:01 AM UTC-5, Philipp Stephani wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: =
1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddi=
ng-left: 1ex;"><br><br><div>On Sat Feb 01 2014 at 07:35:18, Billy O'Neal &l=
t;<a target=3D"_blank" gdf-obfuscated-mailto=3D"IotSwaBvxNQJ" style=3D"colo=
r: rgb(102, 17, 204);">billy...@gmail.com</a>> wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width:=
1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padd=
ing-left: 1ex;"><div dir=3D"ltr">* Returning error codes is error prone in =
that users can forget to check them.</div></blockquote><div><br></div><div>=
Most compilers have an attribute to emit a warning when a result is unused.=
This attribute could be standardized.</div><div> </div></blockquote><=
div>+1 for that idea</div><div> </div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: s=
olid; padding-left: 1ex;"><div dir=3D"ltr">Plus, it can cause confusion for=
callers because parameters are usually used for input, not output.<br></di=
v></blockquote><div><br></div><div>This can be mitigated to some extend by =
not using non-const reference parameters. Using pointers makes the modifica=
tion explicit by having callers take the address. In similar vein, C# requi=
res using the "ref" or "out" keyword both for declaration and at the call s=
ite.</div><div><br></div></blockquote></div><div><br></div><div>This is ano=
ther big question that I have not been able to resolve. I've never quite bo=
ught into one side or the other. Some people just use non-const references =
while others use pointers for the reasons you mentioned above. I hate both =
of these approaches. </div><div><br></div><div>Pointers are also bad:<=
/div><div><ul><li><span style=3D"line-height: normal;">Callers can pass nul=
lptr</span></li><li><span style=3D"line-height: normal;">Whenever I see poi=
nters in code I start thinking about memory management. Do I need to delete=
this pointer? Who owns it? Whats its lifetime?</span></li></ul></div><div>=
<br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2835_25041818.1391280577344--
.
Author: Vladimir Batov <vb.mail.247@gmail.com>
Date: Sun, 2 Feb 2014 11:12:09 +1100
Raw View
Matthew, I probably over-reacted. Apologies. It's just there was so
much absolutism and maximalism and exuberant rejection of everything
you could lay your eyes on is your post. :-) I would probably say it
would not be the best way to communicate if you want your
thoughts/ideas listened to.
As for your "because we have always done it that way", then to me it
sounds more like "because THEY (the old farts who don't know better)
have always done it that way". And I am one of those "farts". And I'd
say that "we have always done it that way" because it's a
well-researched, proven, tested, widely accepted way of doing things.
As for "because X said so", then I am not sure who is that X you keep
referring to? First, *I* expressed my opinion, then I quoted
B.Stroustrup. And when B.Stroustrup or someone of his statue speaks,
I'd strongly suggest you (or I for that matter) simply shut up and
listen and learn. In his GoingNative 2013 talk he re-iterated his
position on pass-by-non-const-reference (he called it "pass a target
object") by saying "output parameters are well-known source of
complexity and confusion... bugs... sometimes it's the best we can do
but... we are throwing away a few hundred years of progress in
notation".
>> std::getline does this....
> That's one situation where out parameters are absolutely the best design.
Well, while watching Alexanrdescu talk I was quite disappointed he
brought it up in the context of efficiency... especially after he
explicitly mentioned reducing the number of reads. OTOH I can think of
improving that "absolutely the best design" by not reading per-line
but the whole file or at least in much bigger chunks. IMO that archaic
std::getline() is only good for reading user input from a console. In
many file formats (XML, C++) "\n" (or any other particular character)
has no special meaning so usefulness/importance of std::getline() is
mute at best.
V.
On Sun, Feb 2, 2014 at 5:49 AM, Matthew Fioravante
<fmatthew5876@gmail.com> wrote:
> My intention was not to be hostile or offend anyone. The point I'm trying=
to
> make is that "because we have always done it that way" or "because X said
> so" is not a good enough reason alone to decide for or against something.
> Not being able to initialize const variables is a good counter argument t=
o
> out parameters. Not being able to compose functions that use out paramete=
rs
> is another good one.
>
> On Saturday, February 1, 2014 1:34:36 AM UTC-5, Billy O'Neal wrote:
>>
>> This really goes back to the formatting question. We are in a position
>> where nobody is completely happy with any of the options.
>>
>> * Throwing exceptions is expensive, extremely verbose, and problematic i=
n
>> many scenarios where code was not written with exception safety in mind
>> * Returning error codes is error prone in that users can forget to check
>> them. Plus, it can cause confusion for callers because parameters are
>> usually used for input, not output.
>> * Thread-local error codes also impose expense, and are even more likely
>> to be unchecked by users, but avoid needing to use a parameter for outpu=
t.
>> * Returning an Expected or similar object makes unpacking the value
>> relatively opaque (e.g. encouraging assignments in conditionals), and re=
lies
>> on a feature whose future impact on maintainability is unknown.
>>
>> Arguing about which one is the best to use will never end, because there
>> are contrived scenarios that might cause someone to choose each model.
>
>
> I came out of this thread more confused and bewildered than when I entere=
d!
> Coming out of this discussion what could be a good paper is someone
> discussing all of the different ways to handle "output" from functions wi=
th
> their merits and drawbacks. Some of the techniques will lend themselves v=
ery
> well to certain situations while others not so much.
>
>
>> std::getline does this. And this is one of the parts of iostreams that d=
o
>> work well; e.g. both Andrei Alexandrescu and Stephan T. Lavavej discusse=
d
>> good reasons for that design in Andrei's Going Native 2013 talk (jump to
>> approximately 50 minutes in). None of those good reasons apply for built=
in
>> types like ints though.
>
>
> That's one situation where out parameters are absolutely the best design.
> When you have a container and need to repeatedly call the method over and
> over again to replace the contents, returning the data simply cannot work
> efficiently.
>
>
> On Saturday, February 1, 2014 5:39:12 AM UTC-5, Daniel Kr=C3=BCgler wrote=
:
>>
>> 2014-02-01 Billy O'Neal <billy...@gmail.com>:
>>
>> > Hmmmm... I stand slightly corrected. I was under the impression that
>> > Java's
>> > int parsing worked this way; but looking now it appears that it throws
>> > exceptions. C# has gone this route though:
>> >
>> > http://msdn.microsoft.com/en-us/library/f02979c7(v=3Dvs.110).aspx
>> >
>> > and I've never heard anyone complain about it there. (In contrast, I'v=
e
>> > heard plenty of people complain about the interface that throws
>> > exceptions)
>>
>> The way you would do an attemptive conversion to a number in Java is
>> by passing a ParsePosition object to a Numberformat.parse function,
>>
>>
>> http://docs.oracle.com/javase/6/docs/api/java/text/NumberFormat.html#par=
se%28java.lang.String,%20java.text.ParsePosition%29
>>
>> By this means you get the information whether the conversion failed
>> and if so at which position within the string without involving
>> exceptions. This is quite useful in tolerant string interpretation
>> situations and is similar to the approach of the strtoX functions from
>> <stdlib.h>.
>>
>> I have a lot of experience with the "Try-" approach based on my long
>> history of working with Delphi,
>>
>>
>> http://docwiki.embarcadero.com/Libraries/XE4/de/System.SysUtils.TryStrTo=
Int
>>
>> (and I'm pretty sure that the C# approach got influenced by them). The
>> problem that I often found here is that these functions don't give you
>> the slightest clue *why* the conversion failed, this is the reason why
>> I think that the "fail-position-retrieval" approach is typically more
>> useful in tolerant parsing situations.
>>
> If you use an error_code class which has a set of error condition enum ta=
gs
> built in (like some of the ideas from this thread) instead of a bool, you
> can retrieve that information if you need it. You can also have an
> additional out parameter which gives you the string position. With overlo=
ads
> we can add and remove these levels of detail when they are needed.
>
>
> On Saturday, February 1, 2014 6:24:01 AM UTC-5, Philipp Stephani wrote:
>>
>>
>>
>> On Sat Feb 01 2014 at 07:35:18, Billy O'Neal <billy...@gmail.com> wrote:
>>>
>>> * Returning error codes is error prone in that users can forget to chec=
k
>>> them.
>>
>>
>> Most compilers have an attribute to emit a warning when a result is
>> unused. This attribute could be standardized.
>>
>
> +1 for that idea
>
>>>
>>> Plus, it can cause confusion for callers because parameters are usually
>>> used for input, not output.
>>
>>
>> This can be mitigated to some extend by not using non-const reference
>> parameters. Using pointers makes the modification explicit by having cal=
lers
>> take the address. In similar vein, C# requires using the "ref" or "out"
>> keyword both for declaration and at the call site.
>>
>
> This is another big question that I have not been able to resolve. I've
> never quite bought into one side or the other. Some people just use
> non-const references while others use pointers for the reasons you mentio=
ned
> above. I hate both of these approaches.
>
> Pointers are also bad:
>
> Callers can pass nullptr
> Whenever I see pointers in code I start thinking about memory management.=
Do
> I need to delete this pointer? Who owns it? Whats its lifetime?
>
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/260PWIq_7u0/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Sat, 1 Feb 2014 17:02:10 -0800 (PST)
Raw View
------=_Part_1324_3308597.1391302930080
Content-Type: text/plain; charset=UTF-8
On Saturday, February 1, 2014 7:12:09 PM UTC-5, Vladimir Batov wrote:
>
> THEY (the old farts who don't know better)
I never said this nor intended it. I have nothing but respect for Bjarne
and the other pioneers and leaders of the C++ community. What I am saying
(with all respect) is that while I highly regard the opinion of experts, I
think it is an error to just accept everything you hear at face value
without thinking about it yourself and understanding how they came to that
conclusion.
Well, while watching Alexanrdescu talk I was quite disappointed he
> brought it up in the context of efficiency... especially after he
> explicitly mentioned reducing the number of reads. OTOH I can think of
> improving that "absolutely the best design" by not reading per-line
> but the whole file or at least in much bigger chunks. IMO that archaic
> std::getline() is only good for reading user input from a console. In
> many file formats (XML, C++) "\n" (or any other particular character)
> has no special meaning so usefulness/importance of std::getline() is
> mute at best.
>
getline()/fgets() is buffered. The file is read in blocks into a buffer
managed by the fstream/FILE*. getline and fgets simply searches the buffer
for the next newline and then copies the bytes to the destination object,
rereading new blocks as necessary.
In terms of efficiency getline() and fgets() is not the best because it
does this extra copy. fgets() is even sillier because it doesn't tell you
the length of the line! You need a strlen() call for that, which means the
code is walking the same buffer twice for no good reason. Once to find the
newline, and then once again to compute the length.
The most efficient method is instead to just return a pointer to the
internally managed buffer. I'd love to see a file interface that does that.
I measured a 2x speedup for parse heavy code which did this trick with a
custom file class that combined its internal buffering with the line
parsing logic.
But if we're talking about a getline() interface which does a copy into a
separate container, out parameters are the best way to do it. Another
example is std::copy(), you can't really return the thing you're copying
to. I suppose that one high level distinction one can acquire from this
discussion is that return values are typically used to create new objects
while out parameters are used to mutate pre-existing objects. In this case
getline() is rightly designed to modify an existing pre-allocated line
buffer (implemented as std::string) instead of creating (memory
allocations, one per line) a new separate buffer for every line.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1324_3308597.1391302930080
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, February 1, 2014 7:12:09 PM UTC-5, Vl=
adimir Batov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204)=
; border-left-style: solid; padding-left: 1ex;">THEY (the old farts who don=
't know better) </blockquote><div>I never said this nor intended it. I=
have nothing but respect for Bjarne and the other pioneers and leaders of =
the C++ community. What I am saying (with all respect) is that while I high=
ly regard the opinion of experts, I think it is an error to just accept eve=
rything you hear at face value without thinking about it yourself and under=
standing how they came to that conclusion.</div><div><br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Well, while watching Alexanrdescu talk I was qu=
ite disappointed he
<br>brought it up in the context of efficiency... especially after he
<br>explicitly mentioned reducing the number of reads. OTOH I can think of
<br>improving that "absolutely the best design" by not reading per-line
<br>but the whole file or at least in much bigger chunks. IMO that archaic
<br>std::getline() is only good for reading user input from a console. In
<br>many file formats (XML, C++) "\n" (or any other particular character)
<br>has no special meaning so usefulness/importance of std::getline() is
<br>mute at best.
<br></blockquote><div><br></div><div>getline()/fgets() is buffered. The fil=
e is read in blocks into a buffer managed by the fstream/FILE*. getline and=
fgets simply searches the buffer for the next newline and then copies the =
bytes to the destination object, rereading new blocks as necessary. </=
div><div><br></div><div>In terms of efficiency getline() and fgets() is not=
the best because it does this extra copy. fgets() is even sillier because =
it doesn't tell you the length of the line! You need a strlen() call for th=
at, which means the code is walking the same buffer twice for no good reaso=
n. Once to find the newline, and then once again to compute the length.&nbs=
p;</div><div><br></div><div>The most efficient method is instead to just re=
turn a pointer to the internally managed buffer. I'd love to see a file int=
erface that does that. I measured a 2x speedup for parse heavy code which d=
id this trick with a custom file class that combined its internal buffering=
with the line parsing logic.</div><div><br></div><div>But if we're talking=
about a getline() interface which does a copy into a separate container, o=
ut parameters are the best way to do it. Another example is std::copy(), yo=
u can't really return the thing you're copying to. I suppose that one high =
level distinction one can acquire from this discussion is that return value=
s are typically used to create new objects while out parameters are used to=
mutate pre-existing objects. In this case getline() is rightly designed to=
modify an existing pre-allocated line buffer (implemented as std::string) =
instead of creating (memory allocations, one per line) a new separate buffe=
r for every line.</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1324_3308597.1391302930080--
.
Author: Roland Bock <rbock@eudoxos.de>
Date: Sun, 02 Feb 2014 09:48:11 +0100
Raw View
On 2014-02-02 02:02, Matthew Fioravante wrote:
>
> But if we're talking about a getline() interface which does a copy
> into a separate container, out parameters are the best way to do it.
Have you seen this?
http://ericniebler.com/2013/10/13/out-parameters-vs-move-semantics/
Eric Niebler suggests a stateful object which yields a very neat and
efficient interface.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 02 Feb 2014 19:01:58 +0100
Raw View
Le 02/02/14 09:48, Roland Bock a =C3=A9crit :
> On 2014-02-02 02:02, Matthew Fioravante wrote:
>> But if we're talking about a getline() interface which does a copy
>> into a separate container, out parameters are the best way to do it.
> Have you seen this?
> http://ericniebler.com/2013/10/13/out-parameters-vs-move-semantics/
>
> Eric Niebler suggests a stateful object which yields a very neat and
> efficient interface.
>
I like this as there are no more out parameters. However it doesn't take=20
in account how to report a failure.
Maybe the value_type of the iterator could be expected<string>.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 02 Feb 2014 19:42:37 +0100
Raw View
This is a multi-part message in MIME format.
--------------090302090305000402020703
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 01/02/14 06:34, Vicente J. Botet Escriba a =C3=A9crit :
> Le 01/02/14 04:21, Matthew Fioravante a =C3=A9crit :
>>
>> On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R. wrote:
>>
>> Maybe you are looking for the support given in the header
>> <system_error> from the error handling library.
>>
>>
>> Perhaps, but in many cases I like to specify my own set of error=20
>> codes. Using an enum is even better because you have the compiler=20
>> help you ensure you handle them all with -Wswitch.
>>
>>
> expected<T, myEnum> could be used in these cases.
>>
>>
>> On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa wrote:
>>
>> ...
>> The above isn't exactly what we had. The above is slightly more
>> like an exception allowing any type to be stored in the error. We
>> only permitted storing our base complex error type (similar to
>> std::system_error in some regards but avoided any heap allocation
>> and had a bunch of features irrelevant to this discussion). But
>> it gives the general gist of how it could be used in a more
>> generic setting as an alternative to exceptions. It obviously
>> doesn't solve issues arising from avoiding using exceptions in
>> constructors and overloaded operators though.
>>
>>
>> I like your idea. A thread-local error state such as errno is not so=20
>> evil as people make it out to be. As you say it certainly makes the=20
>> stack propagation (aka the football part) easier. There was a lot of=20
>> backlash against the errno pattern in the string-to-int thread. One=20
>> thing I'd be curious about is what updating thread local state means=20
>> for inlining. What kind of optimization is inhibited? The compiler=20
>> can easily optimize out an unused return value but for a=20
>> global/thread-local, it has no idea what the side effects could be.
> I guess everyone agree here.
>>
>>
>> OTOH I can't think of one single std. library component doing that.
>> Please do not get me wrong. I am not judging/criticizing your
>> programming style and personal preferences. Only saying that IMO
>> that
>> choice will push so many people away (for practical, stylistic, etc.
>> reasons) even before we get into a serious discussion.
>>
>> Just my 2c.
>> V.
>>
>>
>> I like reference out parameters for the same reasons as the previous=20
>> poster. They work very well for precedural interfaces with overloading.
>>
>> int val;
>> if(!fromString("1234", val)) {
>> //handle error
>> }
>>
> We are not discussing here only about a fromString function but about=20
> a generic retcode class. The user can define both with expected
>
> expected<void, error_code> from_string(std::string, T&);
> expected<T, error_code> from_string(std::string);
>
>
> Both are useful and each one has its advantages and liabilities. But=20
> both make use of the same generic expect class.
>
> Whether the expected destructor must terminate if the error_code has=20
> not been inspected is subject to discussion. We could as well have two=20
> classes, one that lets the user the responsability to do whatever she=20
> wants and don't need to track if the error_code/exception has been=20
> inspected and one one wrapper that request for inspection.
>
> inspect_guard<expected<void, error_code>> from_string(std::string, T);
> inspect_guard<expected<T, error_code>> from_string(std::string);
>
> or an alias template
>
> using expected_guard =3D inspect_guard<expected<T, E>>;
Thanks to Bjorn Reese that sent me this pointer [1]. After a reading it=20
seems to me that we could have a retcode class that do something as=20
std::terminate() when the error is ignored. This class could be used=20
then as the error type parameter of expected and so if expected has a=20
error that is not inspected, the destructor of this retcode class will=20
finish by calling std::terminate().
expected<T, not_ignored<error_code>> from_string(std::string);
Both classes can be proposed almost independently and could work=20
together. Lets see if there is a C++ transparent way to check if the=20
error code has been inspected using the conversion operators.
|operatorE(){m_handled =3Dtrue;returnm_error;}
|
A function ignore could be added so that we can convert an expected<T,=20
not_ignored<error_code>> to an expected<T, error_code>
expected<T, error_code> e =3D ignore(from_string(std::string));
Vicente
[1] *A Return Type That Doesn=E2=80=99t Like Being Ignored=20
*http://accu.org/var/uploads/journals/overload53-FINAL.pdf
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------090302090305000402020703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 01/02/14 06:34, Vicente J. Botet
Escriba a =C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:52EC875B.2000206@wanadoo.fr" type=3D"cite">
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
<div class=3D"moz-cite-prefix">Le 01/02/14 04:21, Matthew Fioravante
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Monday, January 27, 2014 2:06:59 AM UTC-5, Diego R. wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div dir=3D"ltr">Maybe you are looking for the support given
in the header <system_error> from the error handling
library.</div>
</blockquote>
<div><br>
</div>
<div>Perhaps, but in many cases I like to specify my own set
of error codes. Using an enum is even better because you
have the compiler help you ensure you handle them all with
-Wswitch.=C2=A0</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
expected<T, myEnum> could be used in these cases.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
On Monday, January 27, 2014 7:13:58 PM UTC-5, Brendon Costa
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">
<div dir=3D"ltr">
<div>...</div>
<div>The above isn't exactly what we had. The above is
slightly more like an exception allowing any type to
be stored in the error. We only permitted storing our
base complex error type (similar to std::system_error
in some regards but avoided any heap allocation and
had a bunch of features irrelevant to this
discussion). But it gives the general gist of how it
could be used in a more generic setting as an
alternative to exceptions. It obviously doesn't solve
issues arising from avoiding using exceptions in
constructors and overloaded operators though.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I like your idea. A thread-local error state such as
errno is not so evil as people make it out to be. As you
say it certainly makes the stack propagation (aka the
football part) easier. There was a lot of backlash against
the errno pattern in the string-to-int thread. One thing
I'd be curious about is what updating thread local state
means for inlining. What kind of optimization is
inhibited? The compiler can easily optimize out an unused
return value but for a global/thread-local, it has no idea
what the side effects could be.</div>
</div>
</div>
</blockquote>
I guess everyone agree here.<br>
<blockquote
cite=3D"mid:26de4e3a-c268-417f-b1b7-705dc4770215@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div><br>
</div>
<br>
<div>=C2=A0
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x
0.8ex; border-left-width: 1px; border-left-color:
rgb(204, 204, 204); border-left-style: solid;
padding-left: 1ex;">OTOH I can't think of one single
std. library component doing that.=C2=A0<br>
Please do not get me wrong. I am not judging/criticizing
your=C2=A0<br>
programming style and personal preferences. Only saying
that IMO that=C2=A0<br>
choice will push so many people away (for practical,
stylistic, etc.=C2=A0<br>
reasons) even before we get into a serious discussion.=C2=
=A0<br>
<br>
Just my 2c.=C2=A0<br>
V.=C2=A0<br>
</blockquote>
</div>
<div><br>
</div>
<div>I like reference out parameters for the same reasons as
the previous poster. They work very well for precedural
interfaces with overloading.</div>
<div><br>
</div>
<div>int val;</div>
<div>if(!fromString("1234", val)) {<br>
=C2=A0 //handle error</div>
<div>}</div>
<div><br>
</div>
</div>
</div>
</blockquote>
We are not discussing here only about a fromString function but
about a generic retcode class. The user can define both with
expected<br>
<br>
expected<void, error_code> from_string(std::string, T&);<br=
>
expected<T, error_code> from_string(std::string);<br>
<br>
<br>
Both are useful and each one has its advantages and liabilities.
But both make use of the same generic expect class.<br>
<br>
Whether the expected destructor must terminate if the error_code
has not been inspected is subject to discussion. We could as well
have two classes, one that lets the user the responsability to do
whatever she wants and don't need to track if the
error_code/exception has been inspected and one one wrapper that
request for inspection. <br>
<br>
inspect_guard<expected<void, error_code>>
from_string(std::string, T);<br>
inspect_guard<expected<T, error_code>>
from_string(std::string);<br>
<br>
or an alias template<br>
<br>
using expected_guard =3D inspect_guard<expected<T, E>>;<b=
r>
</blockquote>
<br>
Thanks to Bjorn Reese that sent me this pointer [1]. After a reading
it seems to me that we could have a retcode class that do something
as std::terminate() when the error is ignored. This class could be
used then as the error type parameter of expected and so if expected
has a error that is not inspected, the destructor of this retcode
class will finish by calling std::terminate(). <br>
<br>
=C2=A0=C2=A0=C2=A0 expected<T, not_ignored<error_code>>
from_string(std::string);<br>
<br>
Both classes can be proposed almost independently and could work
together. Lets see if there is a C++ transparent way to check if the
error code has been inspected using the conversion operators.<br>
<br>
<code class=3D"prettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><span style=3D"co=
lor:
#008;" class=3D"styled-by-prettify">operator</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #008;" class=3D"styled-by-prettify">E</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> m_handled </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #008;" class=3D"styled-by-prettify">true</span><spa=
n
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #008;" class=3D"styled-by-prettify">return</span><s=
pan
style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0</span><s=
pan
style=3D"color: #660;" class=3D"styled-by-prettify"></span><span
style=3D"color: #000;" class=3D"styled-by-prettify">m_error</span><=
span
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span
style=3D"color: #800;" class=3D"styled-by-prettify"></span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></code><br>
<br>
A function ignore could be added so that we can convert an
expected<T, not_ignored<error_code>> to an
expected<T, error_code><br>
<br>
=C2=A0=C2=A0=C2=A0 expected<T, error_code> e =3D=C2=A0
ignore(from_string(std::string));<br>
<br>
<br>
Vicente<br>
<br>
[1] <b>A Return Type That Doesn=E2=80=99t Like Being Ignored </b><a cla=
ss=3D"moz-txt-link-freetext" href=3D"http://accu.org/var/uploads/journals/o=
verload53-FINAL.pdf">http://accu.org/var/uploads/journals/overload53-FINAL.=
pdf</a><br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------090302090305000402020703--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 03 Feb 2014 11:45:12 -0500
Raw View
On 2014-01-31 22:21, Matthew Fioravante wrote:
> These are redundant and require either exceptions or reusing a valid int
> value to denote errors. The first requires special care if we change the
> type of val. Imagine changing val to long. The code still compiles just
> fine. The second version avoids the potential bug of changing the type of
> val but is verbose.
> int val = fromString<int>("1234");
You misspelled "auto" :-).
> int val = fromString<decltype(val)>("1234"):
If the type of 'val' is dependent on some other type, you're going to be
using 'decltype' anyway. So I don't see that there's much issue here.
Also, I'm going to echo what Vicente said; if we can't agree on this,
just offer both.
> The only major disadvantage to reference out parameters as mentioned in the
> other thread is that you can't initialize things.
....and you can't make your locals const. I don't consider that "not
major"; for me that's probably the bigger disadvantage.
> For class types, the reference out parameter really doesn't work so well.
> Sometimes you really need to use the constructor instead of default
> constructing and then assigning later. That is not the case here as we are
> talking about assigning to simple ints and floats.
Hmm... actually this is interesting. What if we want at some point to
add an implementation for e.g. std::complex? Or what if users want to
use the same interface for some other type, e.g. a UUID, or
who-knows-what? In those cases, ability to produce a class type as a
result may be interesting.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 03 Feb 2014 12:08:55 -0500
Raw View
On 2014-02-01 01:34, Billy O'Neal wrote:
> We should not make technical decisions about what interface best meets the
> scenarios for which a library is designed based on what's "popular." If out
> parameters result in the most maintainable code in real programs, then out
> parameters need to be discussed, regardless of people's "opinions." This
> can only come from growing a library into the role.
In terms of existing usage, Qt likes to return the value, and take an
*optional* out parameter for the status code. However, I can't say I
don't find that awkward :-). It also doesn't make it easy to provide a
fallback value.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.info>
Date: Mon, 03 Feb 2014 10:03:45 -0800
Raw View
Em seg 03 fev 2014, =E0s 12:08:55, Matthew Woehlke escreveu:
> On 2014-02-01 01:34, Billy O'Neal wrote:
> > We should not make technical decisions about what interface best meets =
the
> > scenarios for which a library is designed based on what's "popular." If
> > out
> > parameters result in the most maintainable code in real programs, then =
out
> > parameters need to be discussed, regardless of people's "opinions." Thi=
s
> > can only come from growing a library into the role.
>=20
> In terms of existing usage, Qt likes to return the value, and take an
> *optional* out parameter for the status code. However, I can't say I
> don't find that awkward :-). It also doesn't make it easy to provide a
> fallback value.
Which goes back to what I said: people doing conversions from string to an=
=20
integer type are, in 99.9% of the cases, trying to get the integer value. Y=
ou=20
can argue how many of them are also checking for correctness, but you must=
=20
agree that it's less than that. And that people checking for correctness bu=
t=20
not interested in the actual value is vanishingly small.
That's why the status is optional.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 03 Feb 2014 13:57:16 -0500
Raw View
On 2014-02-03 13:03, Thiago Macieira wrote:
> Em seg 03 fev 2014, =C3=A0s 12:08:55, Matthew Woehlke escreveu:
>> On 2014-02-01 01:34, Billy O'Neal wrote:
>>> We should not make technical decisions about what interface best meets =
the
>>> scenarios for which a library is designed based on what's "popular." If
>>> out
>>> parameters result in the most maintainable code in real programs, then =
out
>>> parameters need to be discussed, regardless of people's "opinions." Thi=
s
>>> can only come from growing a library into the role.
>>
>> In terms of existing usage, Qt likes to return the value, and take an
>> *optional* out parameter for the status code. However, I can't say I
>> don't find that awkward :-). It also doesn't make it easy to provide a
>> fallback value.
>
> Which goes back to what I said: people doing conversions from string to a=
n
> integer type are, in 99.9% of the cases, trying to get the integer value.=
You
> can argue how many of them are also checking for correctness, but you mus=
t
> agree that it's less than that. And that people checking for correctness =
but
> not interested in the actual value is vanishingly small.
>
> That's why the status is optional.
Oh, don't get me wrong, I agree that the status should be optional. The=20
point was that IMHO Qt's API, when I need the status, feels clunky=20
(mostly due to the status being an output parameter). As such, it's hard=20
to imagine that having the more-important *value* as an output parameter=20
would be an improvement :-).
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 03 Feb 2014 11:53:15 -0800
Raw View
Em seg 03 fev 2014, =E0s 13:57:16, Matthew Woehlke escreveu:
> Oh, don't get me wrong, I agree that the status should be optional. The=
=20
> point was that IMHO Qt's API, when I need the status, feels clunky=20
> (mostly due to the status being an output parameter). As such, it's hard=
=20
> to imagine that having the more-important *value* as an output parameter=
=20
> would be an improvement :-).
If you have a suggestion on how to improve it, I'm listening.
I was planning on doing some work on those functions this week anyway=20
(actually, I had planned for last week). They're missing the ability to par=
se=20
a number with more text at the end and return the end pointer.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.