primitive function input/output param encapsulation..

[Chris M. Thomasson]

I am wondering what everybody thinks about the following, fairly crude
attempt at a "free-function" input/output parameter "encapsulation method":
_______________________________________
#include <cstdio>


struct func_foo
{
struct input
{
int a;
int b;
};

struct output
{
int a;
int b;
int c;
};

static output exec(input const& i)
{
output o = {
i.a + 1,
i.b + 2,
(i.a + i.b) / 2
};

return o;
}
};


int main(void)
{
func_foo::input i = { 1, 2 };

func_foo::output o = func_foo::exec(i);

std::printf("o:(a:%u, b:%u, c:%u)\n", o.a, o.b, o.c);

return 0;
}
_______________________________________


So far, this seems fairly clean to me, well, using struct as a quasi
namespace aside for a moment...

Thanks.

[Alf P. Steinbach]

It's hard top come up with a good name for `exec` here, but I've landed
on `result_for`, because that makes the calling code readable:

`func_foo::result_for(i )`.

C++11 added support that means the input structure can be specified
inline, as in the call `func_foo::exec({1, 2, 3})`.

C++17 adds support for returning multiple values from a function, here's
an example from ¹a Stack Overflow Q/A:


[code]
#include <tuple>

using namespace std;

tuple<int, int> divide(int dividend, int divisor) {
return {dividend / divisor, dividend % divisor};
}

#include <iostream>

int main() {
auto [quotient, remainder] = divide(14, 3);

cout << quotient << ',' << remainder << endl;
}
[/code]


Cheers!,

- Alf

Links:
¹ <url: http://stackoverflow.com/a/16516315/464581>

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> C++17 adds support for returning multiple values from a function

Structured bindings have nothing to do with "returning multiple values
from a function".

[Alf P. Steinbach]

Forks have nothing to do with eating.

Cheers & hth.,

- Alf

[Ben Bacarisse]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
<snip>

> C++17 adds support for returning multiple values from a function,

> here's an example from ąa Stack Overflow Q/A:

>
> [code]
> #include <tuple>
>
> using namespace std;
>
> tuple<int, int> divide(int dividend, int divisor) {
> return {dividend / divisor, dividend % divisor};
> }

I think this could be explained more clearly. That looks to me like a
pre-C++17 function that returns a single value.

> #include <iostream>
>
> int main() {
> auto [quotient, remainder] = divide(14, 3);

I think this is the new part. In C++ this is called a decomposition
declaration (though the gcc docs call it a structured declaration).
Other languages would call it a de-structuring binding or a pattern
match.

I.e. the new part is the syntax to decompose a single, structured value.

>
> cout << quotient << ',' << remainder << endl;
> }
> [/code]

<snip>
--
Ben.

[David Brown]

On 10/01/17 13:09, Ben Bacarisse wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
> <snip>
>> C++17 adds support for returning multiple values from a function,
>> here's an example from ąa Stack Overflow Q/A:
>>
>> [code]
>> #include <tuple>
>>
>> using namespace std;
>>
>> tuple<int, int> divide(int dividend, int divisor) {
>> return {dividend / divisor, dividend % divisor};
>> }

Alternatively:

auto divide(int dividend, int divisor) {
return std::make_tuple(dividend / divisor, dividend % divisor);

}

>
> I think this could be explained more clearly. That looks to me like a
> pre-C++17 function that returns a single value.

It is. But that one value is a tuple of two parts - it is (becoming)
the common idiom for returning multiple values from a function. Unless
someone figures out a better syntax for later C++ standards, this is as
close to multiple return values as we can get. (C and C++ would, IMHO,
have been much nicer languages without the "comma operator" - and we
would by now have had a simpler multiple return value syntax. But as we
say in Norway, "done is done and eaten is eaten".)

>
>> #include <iostream>
>>
>> int main() {
>> auto [quotient, remainder] = divide(14, 3);
>
> I think this is the new part. In C++ this is called a decomposition
> declaration (though the gcc docs call it a structured declaration).
> Other languages would call it a de-structuring binding or a pattern
> match.

C++ calls it "structured bindings", as far as I am aware, as does gcc:

<https://skebanga.github.io/structured-bindings/>
<http://wg21.link/P0144r2>

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> On 10/01/17 13:09, Ben Bacarisse wrote:
>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> <snip>
>>> C++17 adds support for returning multiple values from a function,
>>> here's an example from ąa Stack Overflow Q/A:
>>>
>>> [code]
>>> #include <tuple>
>>>
>>> using namespace std;
>>>
>>> tuple<int, int> divide(int dividend, int divisor) {
>>> return {dividend / divisor, dividend % divisor};
>>> }
>
> Alternatively:
>
> auto divide(int dividend, int divisor) {
> return std::make_tuple(dividend / divisor, dividend % divisor);
> }
>
>>
>> I think this could be explained more clearly. That looks to me like a
>> pre-C++17 function that returns a single value.
>
> It is. But that one value is a tuple of two parts - it is (becoming)
> the common idiom for returning multiple values from a function. Unless
> someone figures out a better syntax for later C++ standards, this is as
> close to multiple return values as we can get.

Sure. I'm just saying (a) it's not new and (b) it's not really multiple
values. Even old ANSI C can return a struct, though it was fiddly to
set up due to limitations on initialisers. I'm not sure it really helps
anyone to suggest this is a way to do some new thing called "returning
multiple values".

<snip>

>>> #include <iostream>
>>>
>>> int main() {
>>> auto [quotient, remainder] = divide(14, 3);
>>
>> I think this is the new part. In C++ this is called a decomposition
>> declaration (though the gcc docs call it a structured declaration).
>> Other languages would call it a de-structuring binding or a pattern
>> match.
>
> C++ calls it "structured bindings", as far as I am aware, as does gcc:

My copy of the C++ draft describes the under the heading "decomposition
declaration" and the word "structured" does not appear as far as I can
tell. But there have been lots of names used all over the place in the
build-up to the proposal and, presumably, C++17 is not yet published so
the name is probably still up for grabs.

<snip>
--
Ben.

[Alf P. Steinbach]

On 10.01.2017 16:54, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/01/17 13:09, Ben Bacarisse wrote:
>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>> <snip>
>>>> C++17 adds support for returning multiple values from a function,

>>>> here's an example from ¹a Stack Overflow Q/A:

>>>>
>>>> [code]
>>>> #include <tuple>
>>>>
>>>> using namespace std;
>>>>
>>>> tuple<int, int> divide(int dividend, int divisor) {
>>>> return {dividend / divisor, dividend % divisor};
>>>> }
>>
>> Alternatively:
>>
>> auto divide(int dividend, int divisor) {
>> return std::make_tuple(dividend / divisor, dividend % divisor);
>> }
>>
>>>
>>> I think this could be explained more clearly. That looks to me like a
>>> pre-C++17 function that returns a single value.
>>
>> It is. But that one value is a tuple of two parts - it is (becoming)
>> the common idiom for returning multiple values from a function. Unless
>> someone figures out a better syntax for later C++ standards, this is as
>> close to multiple return values as we can get.
>
> Sure. I'm just saying (a) it's not new and (b) it's not really multiple
> values.

What would be?

> Even old ANSI C can return a struct, though it was fiddly to
> set up due to limitations on initialisers. I'm not sure it really helps
> anyone to suggest this is a way to do some new thing called "returning
> multiple values".

In practice it is a new thing, as I see it. Before C++17 one would have
to use cumbersome `std::tie` to split the composite return value, and so
one was reluctant to design with such functions. Now it's a breeze.

Consider old

// C++11

#include <tuple>
using namespace std;

auto divide( int const dividend, int const divisor )
-> tuple<int, int>
{ return make_tuple( dividend / divisor, dividend % divisor ); }

#include <iostream>
auto main()
-> int
{
int quotient, remainder;
tie( quotient, remainder ) = divide(14, 3);

cout << quotient << ',' << remainder << endl;
}

versus new

// C++17?

#include <tuple>
using namespace std;

auto divide( int const dividend, int const divisor )
{ return make_tuple( dividend / divisor, dividend % divisor ); }

#include <iostream>
auto main()
-> int
{
auto[quotient, remainder] = divide( 14, 3 );

cout << quotient << ',' << remainder << endl;
}

I installed MingW g++ (STL's Nuwen distro) to try this but it doesn't
like the syntax, so I have no compiler that likes it. Possibly the dang
compiler. Or clang, as some people misread the name.


Cheers!,

- Alf

[Melzzzzz]

On Tue, 10 Jan 2017 18:59:32 +0100

"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:

gcc6 doesn't support it. gcc7 does. clang 3.9 doesn't support it. 4.0
does.

--
press any key to continue or any other to quit...

[Ben Bacarisse]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

> On 10.01.2017 16:54, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>> On 10/01/17 13:09, Ben Bacarisse wrote:
>>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>>> <snip>
>>>>> C++17 adds support for returning multiple values from a function,

>>>>> here's an example from ąa Stack Overflow Q/A:

>>>>>
>>>>> [code]
>>>>> #include <tuple>
>>>>>
>>>>> using namespace std;
>>>>>
>>>>> tuple<int, int> divide(int dividend, int divisor) {
>>>>> return {dividend / divisor, dividend % divisor};
>>>>> }
>>>
>>> Alternatively:
>>>
>>> auto divide(int dividend, int divisor) {
>>> return std::make_tuple(dividend / divisor, dividend % divisor);
>>> }
>>>
>>>>
>>>> I think this could be explained more clearly. That looks to me like a
>>>> pre-C++17 function that returns a single value.
>>>
>>> It is. But that one value is a tuple of two parts - it is (becoming)
>>> the common idiom for returning multiple values from a function. Unless
>>> someone figures out a better syntax for later C++ standards, this is as
>>> close to multiple return values as we can get.
>>
>> Sure. I'm just saying (a) it's not new and (b) it's not really multiple
>> values.
>
> What would be?

Well, if the values are not bound together in some single value, then
that's clearly multiple return values. For example, Common Lisp has
multiple return values, as does (in a much more elaborate way) Prolog.
In some others, like Icon, expressions (including function calls) can
have both a return value and a success status.

>> Even old ANSI C can return a struct, though it was fiddly to
>> set up due to limitations on initialisers. I'm not sure it really helps
>> anyone to suggest this is a way to do some new thing called "returning
>> multiple values".
>
> In practice it is a new thing, as I see it. Before C++17 one would
> have to use cumbersome `std::tie` to split the composite return value,
> and so one was reluctant to design with such functions. Now it's a
> breeze.

Yes, but it's the "destructuring" decomposition declaration that's new,
not the use of an aggregate object as the return value. You can use
C++17's auto [v1, v2] = ... syntax even with an expression that returns
a plain old struct.

<snip>
--
Ben.

[David Brown]

On 10/01/17 18:59, Alf P. Steinbach wrote:

>
> I installed MingW g++ (STL's Nuwen distro) to try this but it doesn't
> like the syntax, so I have no compiler that likes it. Possibly the dang
> compiler. Or clang, as some people misread the name.
>

<https://gcc.godbolt.org/#> is always useful for testing.

[David Brown]

On 10/01/17 16:54, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/01/17 13:09, Ben Bacarisse wrote:
>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>> <snip>
>>>> C++17 adds support for returning multiple values from a function,

>>>> here's an example from ¹a Stack Overflow Q/A:

>>>>
>>>> [code]
>>>> #include <tuple>
>>>>
>>>> using namespace std;
>>>>
>>>> tuple<int, int> divide(int dividend, int divisor) {
>>>> return {dividend / divisor, dividend % divisor};
>>>> }
>>
>> Alternatively:
>>
>> auto divide(int dividend, int divisor) {
>> return std::make_tuple(dividend / divisor, dividend % divisor);
>> }
>>
>>>
>>> I think this could be explained more clearly. That looks to me like a
>>> pre-C++17 function that returns a single value.
>>
>> It is. But that one value is a tuple of two parts - it is (becoming)
>> the common idiom for returning multiple values from a function. Unless
>> someone figures out a better syntax for later C++ standards, this is as
>> close to multiple return values as we can get.
>
> Sure. I'm just saying (a) it's not new and (b) it's not really multiple
> values. Even old ANSI C can return a struct, though it was fiddly to
> set up due to limitations on initialisers.

All true, of course.

> I'm not sure it really helps
> anyone to suggest this is a way to do some new thing called "returning
> multiple values".

As Alf says, it is a new way to make it significantly easier to return
multiple values. And although it is returning a single multi-value type
(a tuple), that is the way many languages handle "return multiple values".

Python supports multiple return values in functions:

def f() : return 1, 2

But you can still write:

x = f()
type(x)
# <type 'tuple'>

So the idiom above is a function returning multiple values in C++ in
exactly the same way as in Python. The new structured bindings makes it
easier to use.

>
> <snip>
>>>> #include <iostream>
>>>>
>>>> int main() {
>>>> auto [quotient, remainder] = divide(14, 3);
>>>
>>> I think this is the new part. In C++ this is called a decomposition
>>> declaration (though the gcc docs call it a structured declaration).
>>> Other languages would call it a de-structuring binding or a pattern
>>> match.
>>
>> C++ calls it "structured bindings", as far as I am aware, as does gcc:
>
> My copy of the C++ draft describes the under the heading "decomposition
> declaration" and the word "structured" does not appear as far as I can
> tell. But there have been lots of names used all over the place in the
> build-up to the proposal and, presumably, C++17 is not yet published so
> the name is probably still up for grabs.
>

I guess they will be called "decomposition declarations" in standardese,
and "structure bindings" in the common tongue.

From <http://en.cppreference.com/w/cpp/language/auto> we have: "A
decomposition declaration, informally known as structured binding."

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> On 10/01/17 16:54, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>> On 10/01/17 13:09, Ben Bacarisse wrote:
>>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>>> <snip>
>>>>> C++17 adds support for returning multiple values from a function,

>>>>> here's an example from ąa Stack Overflow Q/A:

>>>>>
>>>>> [code]
>>>>> #include <tuple>
>>>>>
>>>>> using namespace std;
>>>>>
>>>>> tuple<int, int> divide(int dividend, int divisor) {
>>>>> return {dividend / divisor, dividend % divisor};
>>>>> }
>>>
>>> Alternatively:
>>>
>>> auto divide(int dividend, int divisor) {
>>> return std::make_tuple(dividend / divisor, dividend % divisor);
>>> }
>>>
>>>>
>>>> I think this could be explained more clearly. That looks to me like a
>>>> pre-C++17 function that returns a single value.
>>>
>>> It is. But that one value is a tuple of two parts - it is (becoming)
>>> the common idiom for returning multiple values from a function. Unless
>>> someone figures out a better syntax for later C++ standards, this is as
>>> close to multiple return values as we can get.
>>
>> Sure. I'm just saying (a) it's not new and (b) it's not really multiple
>> values. Even old ANSI C can return a struct, though it was fiddly to
>> set up due to limitations on initialisers.
>
> All true, of course.
>
>> I'm not sure it really helps
>> anyone to suggest this is a way to do some new thing called "returning
>> multiple values".
>
> As Alf says, it is a new way to make it significantly easier to return
> multiple values.

I'd say that the new syntax makes it easier to use the parts of the
return value. It is no easier to return the value than it was before.

I think it's unhelpful to conflate returning a tuple (which is not new)
with the new syntax for destructuring a value (which might not be the
return from any function). But if you don't mind putting them all into
the concept of "returning multiple values" I will hold my tongue.

The phrase is fine in casual conversation, but I thought the post was
slightly misleading as an instructional one about the technique.

> And although it is returning a single multi-value
> type (a tuple), that is the way many languages handle "return multiple
> values".
>
> Python supports multiple return values in functions:
>
> def f() : return 1, 2

It supports returning a tuple. If you go this route, you will find
almost no language unable to return multiple values. What then do we
call Common Lisp's multiple return values?

> But you can still write:
>
> x = f()
> type(x)
> # <type 'tuple'>
>
> So the idiom above is a function returning multiple values in C++ in
> exactly the same way as in Python.

Or the idiom above is a function returning a single value in C++ in
exactly the same was as in Python. I'm not sure why Pyhton's tuples
should persuade me when C++'s don't! I agree that they are the same.

> The new structured bindings makes it easier to use.

Undoubtedly. It's a hugely useful feature. Languages like ML have had
type inference and structure pattern matching (they tend to go together)
for decades and I miss them when they're not there.

(For completeness, in Python you can write x,y = f() to pull the tuple
apart.)

<snip>
--
Ben.

[David Brown]

On 11/01/17 00:22, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> On 10/01/17 16:54, Ben Bacarisse wrote:
>>> David Brown <david...@hesbynett.no> writes:
>>>
>>>> On 10/01/17 13:09, Ben Bacarisse wrote:
>>>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>>>> <snip>
>>>>>> C++17 adds support for returning multiple values from a function,

>>>>>> here's an example from ¹a Stack Overflow Q/A:

I consider returning multiple values, and using them, as part of the
same process. Without structured bindings, it is a bit inconvenient to
use tuples to return multiple values from functions - with structured
bindings, it is easier and thus a more useful technique. It would be
even easier if we could write "return [1, 2];" instead of "return
std::make_tuple(1, 2);", but we have to have something to look forward
to in C++20 :-)

It is true that returning tuples is not only useful with structured
bindings, and structured bindings are not only useful with functions
that return tuples. However, I expect they will often be used in
conjunction and considered together as the normal way to return and use

multiple values from a function.

>

> The phrase is fine in casual conversation, but I thought the post was
> slightly misleading as an instructional one about the technique.

I'll agree that technically it was inaccurate - C++17 adds support for a
new way to use the multiple values returned as a tuple, but not new ways
for the actual return.

>
>> And although it is returning a single multi-value
>> type (a tuple), that is the way many languages handle "return multiple
>> values".
>>
>> Python supports multiple return values in functions:
>>
>> def f() : return 1, 2
>
> It supports returning a tuple. If you go this route, you will find
> almost no language unable to return multiple values. What then do we
> call Common Lisp's multiple return values?

I am not familiar enough with Lisp to comment on it. But in Python,
returning a tuple like this is used for multiple return values, and
often referred to as multiple return values - even though technically it
is only returning a single value of tuple type.

>
>> But you can still write:
>>
>> x = f()
>> type(x)
>> # <type 'tuple'>
>>
>> So the idiom above is a function returning multiple values in C++ in
>> exactly the same way as in Python.
>
> Or the idiom above is a function returning a single value in C++ in
> exactly the same was as in Python. I'm not sure why Pyhton's tuples
> should persuade me when C++'s don't! I agree that they are the same.
>
>> The new structured bindings makes it easier to use.
>
> Undoubtedly. It's a hugely useful feature. Languages like ML have had
> type inference and structure pattern matching (they tend to go together)
> for decades and I miss them when they're not there.
>

I gather pattern matching in C++ is not yet ready for the standards, but
people are working on it. The proposal for structured bindings suggests
pattern matching with structured bindings, but recommends against
including them until pattern matching in general is ready.

> (For completeness, in Python you can write x,y = f() to pull the tuple
> apart.)
>

Yes, that's what you usually write. I only wrote "x = f()" to emphasise
that the Pythonic idiom for returning multiple values is really
returning a single tuple, just like in C++.

[Chris M. Thomasson]

Agreed.

> C++11 added support that means the input structure can be specified
> inline, as in the call `func_foo::exec({1, 2, 3})`.

Indeed. FWIW, sometimes I like to create the "input" structure ahead of
time, especially if it has many "parameters". Another contrived reason
is the ability to reuse a similar "template like" input structure cast
over many calls to (::result_for(i)) in the same scope.

> C++17 adds support for returning multiple values from a function, here's
> an example from ¹a Stack Overflow Q/A:
>
>
> [code]
> #include <tuple>
>
> using namespace std;
>
> tuple<int, int> divide(int dividend, int divisor) {
> return {dividend / divisor, dividend % divisor};
> }
>
> #include <iostream>
>
> int main() {
> auto [quotient, remainder] = divide(14, 3);
>
> cout << quotient << ',' << remainder << endl;
> }
> [/code]

This looks very nice, however, imvvho this seems like a bit of a
"different" language to me. I understand auto, but personally still like
a type name in the source code:
___________________________
auto i0 = 123.0;
auto i1 = 123.0f;

vs:

double i0 = 123.0;
float i1 = 123.0f;
___________________________

Ahh, perhaps I need to brush up on my modern C++ skills!

;^o


FWIW, here is a little example of where I might want to use the input
output binding type thing. Here is a function that can find cycles in
the Mandelbrot set. It uses a slow and fast iteration "pointer",
basically identical to finding cycles in linked lists.

Here is the crude code using the "free-function" input/output
encapsulation "thing":
_____________________________________________
#include <complex>
#include <cstdio>


typedef double ct_float;
typedef std::complex<ct_float> ct_complex;


bool
ct_complex_compare(
ct_complex const& c0,
ct_complex c1,
ct_float epsilon
) {
ct_complex d = c1 - c0;
return std::abs(d) < epsilon;
}


struct mbrot_detect_cycle
{
struct input
{
ct_complex c;
ct_complex z;
ct_float escape;
ct_float epsilon;
unsigned int imax;
};

struct output
{
ct_complex z;
unsigned int i;
bool cycle;
};

static output result_for(input const& in)
{
ct_complex slow = in.z;
ct_complex fast = in.z;

for (unsigned int i = 0; i < in.imax; ++i)
{
slow = slow*slow + in.c;

fast = fast*fast + in.c;
fast = fast*fast + in.c;

if (ct_complex_compare(slow, fast, in.epsilon))
{
return{ slow, i, true };
}

ct_float dis = std::abs(slow);

if (dis > in.escape)
{
return{ slow, i, false };
}

// uncomment following line for progress meter... ;^)
//if (! (i % 10000)) std::printf("i:%u\r", i);
}

return{ slow, in.imax, false };
}
};



int main()
{
{
mbrot_detect_cycle::input in = {
// fine grain epsilon takes many iterations
// for this point (-.75, 0):
{ -.75, 0 },
{ 0, 0 },
2,
.0001,
500000000
};

mbrot_detect_cycle::output out =
mbrot_detect_cycle::result_for(in);

if (out.cycle)
{
std::printf(
"cycle found for in.c:(%f, %f) "
"at out.i:(%u) iterations in.epsilon:(%f)\n",
in.c.real(), in.c.imag(), out.i, in.epsilon);
}

else
{
std::printf(
"** NO ** cycle was found for in.c:(%f, %f) "
"at out.i:(%u) iterations in.epsilon:(%f)\n",
in.c.real(), in.c.imag(), out.i, in.epsilon);
}
}

return 0;
}
_____________________________________________


FWIW, one can try using different points to test. FWIW, I get the
following output for this code:
_____________________________________________
cycle found for in.c:(-0.750000, 0.000000) at out.i:(4291771) iterations
in.epsilon:(0.000100)
_____________________________________________

[Chris M. Thomasson]

^^^^^^^^^^^^^^^^^^^^^^^^^^^

Umm, that should be (ct_complex const& c1):
________________________________________

bool
ct_complex_compare(
ct_complex const& c0,

ct_complex const& c1,

ct_float epsilon
) {
ct_complex d = c1 - c0;
return std::abs(d) < epsilon;
}

________________________________________

Sorry about that nonsense.

[Chris M. Thomasson]

On 1/11/2017 2:50 PM, Chris M. Thomasson wrote:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> };
>
[...]

> mbrot_detect_cycle::input in = {
> // fine grain epsilon takes many iterations
> // for this point (-.75, 0):
> { -.75, 0 },
> { 0, 0 },
> 2,
> .0001,
> 500000000

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> };

Ummm... unsigned int can only be assumed to hold a 16-bit value. AFAICT,
500000000 is out-of-range wrt portability and correctness.

I should have used long here. Sorry.

[Chris M. Thomasson]

Should there be corks on the end of the forks to prevent somebody from
coding something with bugs, where the fork might just have the ability
to harm another entity?

Ahh, the beauty of C and/or C++. You can drive right off a cliff, just
like in real life; but we are sill here as long as some rules are
followed. Here is a possible model to follow:

http://www.stroustrup.com/JSF-AV-rules.pdf

;^)

[Chris M. Thomasson]

On 1/10/2017 12:04 PM, Stefan Ram wrote:

> "Chris M. Thomasson" <inv...@invalid.invalid> writes:
>> i.a + 1,
>> i.b + 2,
>> (i.a + i.b) / 2
>

> One variant might be:
>
> static void escape( void * p )
> { asm volatile( "" : : "g"(p) : "memory" ); }

Not sure what the purpose of this compiler barrier in a function serves
as of now. But, I would call a single compiler barrier with release
memory visibility semantics _after_ setting my state, and _before_
making it _visible_ to any other thread/process.


>
> class averager
> { int a_; int b_; int c_;
> public:
> constexpr averager
> ( int const x, int const y ):
> a_{ x + 1 }, b_{ y + 2 }, c_{ ( x + y )/ 2 } {}
> int a() const { return a_; }
> int b() const { return b_; }
> int c() const { return c_; } };
>
> int main()
> { averager av( 2, 3 );
> int a = av.a(); escape( &a );
> int b = av.b(); escape( &b );
> int c = av.c(); escape( &c ); }

Nice! I was focusing on the decomposition of a free-function wrt its
input/output parts, in the form of POD structs. This is fine though.

Thanks.


>
> But then,
>
> I.24: Avoid adjacent unrelated parameters of the same type
>
> Reason
>
> Adjacent arguments of the same type are easily swapped by
> mistake.
>
> Alternative
>
> Define a struct as the parameter type and name the fields for
> those parameters accordingly
>
> , by which your solution actually is better. Well, I think,
> the guidelines mean that you should use the names, thus,
> replace

>
> input i = { 1, 2 };
>

> by
>
> input i; i.horizontal = 1; i.vertical = 2;
>
> . (Of course not meaningless names such as »a« or »b«.)
>

Its more verbose, but fine; no problem. :^)

[Alf P. Steinbach]

Well, they made a mess of things, but why?

I am ~100% sure that a main problem is that they thought they could
replace intelligence with mechanical rules. For example, the rule that
one should not use `errno` is only meaningful for a dumb programmer who
would use that to communicate failures from his own code. But what is
the result of using dumb programmers to create the system?

Oh, we've seen the result. :(


Cheers!,

- Alf

[Chris M. Thomasson]

On 1/12/2017 10:11 PM, Alf P. Steinbach wrote:
> On 13.01.2017 00:26, Chris M. Thomasson wrote:
>> On 1/10/2017 12:57 AM, Alf P. Steinbach wrote:
>>> On 10.01.2017 08:15, Juha Nieminen wrote:
>>>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>>>> C++17 adds support for returning multiple values from a function
>>>>
>>>> Structured bindings have nothing to do with "returning multiple values
>>>> from a function".
>>>
>>> Forks have nothing to do with eating.
>>
>> Should there be corks on the end of the forks to prevent somebody from
>> coding something with bugs, where the fork might just have the ability
>> to harm another entity?
>>
>> Ahh, the beauty of C and/or C++. You can drive right off a cliff, just
>> like in real life; but we are sill here as long as some rules are
>> followed. Here is a possible model to follow:
>>
>> http://www.stroustrup.com/JSF-AV-rules.pdf
>>
>> ;^)
>
> Well, they made a mess of things, but why?
>
> I am ~100% sure that a main problem is that they thought they could
> replace intelligence with mechanical rules.

There better be a mechanical override that the intelligence can try
before a hidden, hard to find coding failure in the senor array net can
potentially radically expose the ship down to Terra-Contact explosion
like conditions, without an eject; another subject are the ejection
system codes.

Now to think of the correctness of the various dangerous weapons systems.

A lot of detail in creating a warplane.

> For example, the rule that
> one should not use `errno` is only meaningful for a dumb programmer who
> would use that to communicate failures from his own code. But what is
> the result of using dumb programmers to create the system?
>
> Oh, we've seen the result. :(

Indeed! ;^o

Preaching to the choir wrt errno:

search the text in the following page for "errno"->

http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_timedwait.html

http://man7.org/linux/man-pages/man3/sem_wait.3.html

ahhh, semaphores.

;^)

[Chris M. Thomasson]

On 1/14/2017 2:34 PM, Chris M. Thomasson wrote:
> On 1/12/2017 10:11 PM, Alf P. Steinbach wrote:
>> On 13.01.2017 00:26, Chris M. Thomasson wrote:
>>> On 1/10/2017 12:57 AM, Alf P. Steinbach wrote:
>>>> On 10.01.2017 08:15, Juha Nieminen wrote:
>>>>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>>>>> C++17 adds support for returning multiple values from a function
>>>>>
>>>>> Structured bindings have nothing to do with "returning multiple values
>>>>> from a function".
>>>>
>>>> Forks have nothing to do with eating.
>>>
>>> Should there be corks on the end of the forks to prevent somebody from
>>> coding something with bugs, where the fork might just have the ability
>>> to harm another entity?
>>>
>>> Ahh, the beauty of C and/or C++. You can drive right off a cliff, just
>>> like in real life; but we are sill here as long as some rules are
>>> followed. Here is a possible model to follow:
>>>
>>> http://www.stroustrup.com/JSF-AV-rules.pdf
>>>
>>> ;^)
>>
>> Well, they made a mess of things, but why?
>>
>> I am ~100% sure that a main problem is that they thought they could
>> replace intelligence with mechanical rules.
>
> There better be a mechanical override that the intelligence can try

> before a hidden, hard to find coding failure in the senor array net can

^^^^^^^^^^^^^^^^^^^^^
Not senor! damn it.

before a hidden, hard to find coding failure in the _sensor_ array net can

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> On 10.01.2017 08:15, Juha Nieminen wrote:
>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>> C++17 adds support for returning multiple values from a function
>>
>> Structured bindings have nothing to do with "returning multiple values
>> from a function".
>
> Forks have nothing to do with eating.

If you count structs as "returning multiple values from a function",
then you have been able to do that since C++ was invented. It has
nothing to do with C++17.

[Öö Tiib]

On Monday, 16 January 2017 09:06:29 UTC+2, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> > On 10.01.2017 08:15, Juha Nieminen wrote:
> >> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> >>> C++17 adds support for returning multiple values from a function
> >>
> >> Structured bindings have nothing to do with "returning multiple values
> >> from a function".
> >
> > Forks have nothing to do with eating.
>
> If you count structs as "returning multiple values from a function",
> then you have been able to do that since C++ was invented. It has
> nothing to do with C++17.

Capability to return structs by value is actually because of backwards-
compatibility with C. The implicitly defaulted copy constructors
(that have caused lot of defects) are in C++ language likely because
of that feature of C.

[Chris M. Thomasson]

I have always wondered if a weapons system can randomly fire if its
controlling systems are strafed with a stream of bullets that hit in the
right places.