Let's call the <=> operator "trike" because of the math term "trichotomy"

[Rudi Cilibrasi]

What do people call the <=> operator verbally?

It's an important question with the upcoming C++ standard with the new consistent comparison feature!

The name I have heard from the Ruby community is "spaceship operator."
"Spaceship operator" is visually memorable and fun.

Here's another edifying alternative.

The law of trichotomy [3] in math is the theoretical basis for the consistency of this operator and has at least a couple popular variations:

1. any number x is either
a) less than x<0,
b) equal to x=0, or
c) greater than 0 x>0.

2. any numbers (x,y) are related as x<y, x=y, or x>y.

For me the name "trike" refers to the name of the principle that makes this math construction work and it's handy because it is short.

Like

"bang" for ! (exclamation point) and
"splat" or "star" for * (asterisk).

[3]: https://en.wikipedia.org/wiki/Three-way_comparison

Cheers

Rudi

[Öö Tiib]

On Wednesday, 9 May 2018 06:31:41 UTC+3, Rudi Cilibrasi wrote:
> What do people call the <=> operator verbally?

C++ does not have any infrastructures for three way logic. In FORTRAN
there is three way "Arithmetic IF" that made everybody even more nuts
than GOTO. So "spaceship" is fine but I don't think I will use it in
actual code.

[David Brown]

Its primary use is in templates and class definitions in C++20. If a
class defines the "<=>" operator, then it gets default implementations
for the other comparisons for free. The idea is to make orderable types
much simpler and neater. I don't think you'll see much use of the
operator outside of this - compilers will already handle "if (a < b) ...
else if (a > b) ... else ..." as efficiently as possible.

[bol...@cylonhq.com]

Ever get the feeling the commitee has run out of useful things to add to
the language and are now simply justifying their own existence?

Constantly adding syntatic sugar to a language is not a good thing - it means
that increasing numbers of people only ever know a subset of the language and
hence may have problems maintaining code written by others who used another
subset. Plus it makes going for interviews harder since there's ever more to
learn for when the interviewer pulls out the inevitable questions out of
appendix D in whatever C++ book he has on his desk.

[David Brown]

On 09/05/18 10:26, bol...@cylonHQ.com wrote:
> On Wed, 09 May 2018 09:04:26 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/05/18 07:40, Öö Tiib wrote:
>>> On Wednesday, 9 May 2018 06:31:41 UTC+3, Rudi Cilibrasi wrote:
>>>> What do people call the <=> operator verbally?
>>>
>>> C++ does not have any infrastructures for three way logic. In FORTRAN
>>> there is three way "Arithmetic IF" that made everybody even more nuts
>>> than GOTO. So "spaceship" is fine but I don't think I will use it in
>>> actual code.
>>>
>>
>> Its primary use is in templates and class definitions in C++20. If a
>> class defines the "<=>" operator, then it gets default implementations
>> for the other comparisons for free. The idea is to make orderable types
>> much simpler and neater. I don't think you'll see much use of the
>> operator outside of this - compilers will already handle "if (a < b) ...
>> else if (a > b) ... else ..." as efficiently as possible.
>
> Ever get the feeling the commitee has run out of useful things to add to
> the language and are now simply justifying their own existence?

No, I don't. I get the feeling that the committee is made up of people
who work a lot with C++, either as developers, library developers, or
compiler implementers. And one of the things they do is look at
existing code to see if it is long, complicated, error-prone or
duplicated, and try to imagine simplifications. The spaceship operator
is a fine example - it will make many classes and templates a good deal
simpler, clearer, and easier to write.

>
> Constantly adding syntatic sugar to a language is not a good thing - it means
> that increasing numbers of people only ever know a subset of the language and
> hence may have problems maintaining code written by others who used another
> subset.

C++ is developing into a split between "the stuff for experts and
library developers" and "the stuff for application programmers". That's
okay, IMHO. These are often different kinds of programmers with
different needs - but it is great that the same language handles both.

Changes like this have little relevance to application programmers, but
make library coding easier. And that will mean more useful libraries
available for application programmers. It's good all round.

A fair amount of library programming has been pretty hairy. Look at
implementations for std::optional<>, for example - it's hugely
complicated. But with some of the proposals in the works, it will get
vastly simpler.

And if we ever get metaclasses, that will be a major addition to the
language (lots more for people to learn), but allow huge simplifications
in libraries.

You usually only ever need to know a subset of the language and the
library - that is true for any large programming library, or any big
software system.

> Plus it makes going for interviews harder since there's ever more to
> learn for when the interviewer pulls out the inevitable questions out of
> appendix D in whatever C++ book he has on his desk.
>

I don't think that is going to be your biggest problem in interviews,
judging from your posts here. Cheer up a bit, and try to look at the
positive sides of programming - that will make the difference.

[bol...@cylonhq.com]

On Wed, 09 May 2018 10:53:10 +0200
David Brown <david...@hesbynett.no> wrote:

>On 09/05/18 10:26, bol...@cylonHQ.com wrote:
>> Ever get the feeling the commitee has run out of useful things to add to
>> the language and are now simply justifying their own existence?
>
>No, I don't. I get the feeling that the committee is made up of people
>who work a lot with C++, either as developers, library developers, or
>compiler implementers. And one of the things they do is look at
>existing code to see if it is long, complicated, error-prone or
>duplicated, and try to imagine simplifications. The spaceship operator

They seem to take a long time to imagine things then.

>is a fine example - it will make many classes and templates a good deal
>simpler, clearer, and easier to write.

I don't know how it works with templates but I'm not sure why its use is
preferable to the isnan() function which has been around for decades (I assume
thats all its checking for).

>Changes like this have little relevance to application programmers, but
>make library coding easier. And that will mean more useful libraries
>available for application programmers. It's good all round.

So what currently can't be implemented then that this operator will allow?

>A fair amount of library programming has been pretty hairy. Look at
>implementations for std::optional<>, for example - it's hugely
>complicated. But with some of the proposals in the works, it will get
>vastly simpler.

I've never even heard of it.

>And if we ever get metaclasses, that will be a major addition to the
>language (lots more for people to learn), but allow huge simplifications
>in libraries.

If after almost 40 years libraries are still over complicated due to the design
of the language then either A) The language was badly designed from the start or
B) the libraries are trying to be too clever.

>You usually only ever need to know a subset of the language and the
>library - that is true for any large programming library, or any big
>software system.

No, it isn't. While its usually impossible for someone to learn all APIs and
libraries of a language, most languages syntax can be learnt in their entirely.
C++ is the exception to the rule and I know of a couple of good developers
who've dropped the language because of the constant addition of unnecessary
fat to the language that only seems to appeal to language geeks and is of
little to no relevance to application programmers who make up 99.9% of C++'s
user base.

>I don't think that is going to be your biggest problem in interviews,
>judging from your posts here. Cheer up a bit, and try to look at the
>positive sides of programming - that will make the difference.

Don't patronise me you arrogant prick. I was probably already programming while
you were still learning to spell "computer". I respond in kind to the sort of
replies I get.

[David Brown]

On 09/05/18 11:45, bol...@cylonHQ.com wrote:
> On Wed, 09 May 2018 10:53:10 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/05/18 10:26, bol...@cylonHQ.com wrote:
>>> Ever get the feeling the commitee has run out of useful things to add to
>>> the language and are now simply justifying their own existence?
>>
>> No, I don't. I get the feeling that the committee is made up of people
>> who work a lot with C++, either as developers, library developers, or
>> compiler implementers. And one of the things they do is look at
>> existing code to see if it is long, complicated, error-prone or
>> duplicated, and try to imagine simplifications. The spaceship operator
>
> They seem to take a long time to imagine things then.

C++ is currently on an approximately 3 year cycle. That is /fast/. It
takes time for people to use new features, come up with new ideas, and
work them into a usable improvement for the next generation.

>
>> is a fine example - it will make many classes and templates a good deal
>> simpler, clearer, and easier to write.
>
> I don't know how it works with templates but I'm not sure why its use is
> preferable to the isnan() function which has been around for decades (I assume
> thats all its checking for).

Why are you assuming anything here? I /told/ you how it works - and it
has no relation to isnan() at all. Perhaps you imagine that "a <=> b"
simply means "(a < b) || (a == b) || (a > b)" - if so, you are totally
and completely wrong. Read what I wrote earlier in this thread, or look
it up.

<https://en.cppreference.com/w/cpp/language/default_comparisons>

>
>> Changes like this have little relevance to application programmers, but
>> make library coding easier. And that will mean more useful libraries
>> available for application programmers. It's good all round.
>
> So what currently can't be implemented then that this operator will allow?
>

Nothing. But a number of things that /can/ currently be implemented can
be done in a vastly simpler manner with this operator (and the C++20
rules for default operator methods).

>> A fair amount of library programming has been pretty hairy. Look at
>> implementations for std::optional<>, for example - it's hugely
>> complicated. But with some of the proposals in the works, it will get
>> vastly simpler.
>
> I've never even heard of it.

<https://en.cppreference.com/w/cpp/utility/optional>

If you want to know about its implementation, google is your friend.

>
>> And if we ever get metaclasses, that will be a major addition to the
>> language (lots more for people to learn), but allow huge simplifications
>> in libraries.
>
> If after almost 40 years libraries are still over complicated due to the design
> of the language then either A) The language was badly designed from the start or
> B) the libraries are trying to be too clever.
>

C++ always has a baggage of backwards compatibility. And 40 years ago,
people failed to predict how it would be used now - what a surprise!

Improvements in the C++ language have meant that many things that used
to be complicated are now much simpler. A fine example is the "Safe
boolean idiom". Prior to C++11, this was a really ugly mess, and it
took a great deal of effort to understand what was going on. Now it is
trivial.

<https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool>

>> You usually only ever need to know a subset of the language and the
>> library - that is true for any large programming library, or any big
>> software system.
>
> No, it isn't. While its usually impossible for someone to learn all APIs and
> libraries of a language, most languages syntax can be learnt in their entirely.
> C++ is the exception to the rule and I know of a couple of good developers
> who've dropped the language because of the constant addition of unnecessary
> fat to the language that only seems to appeal to language geeks and is of
> little to no relevance to application programmers who make up 99.9% of C++'s
> user base.

1. There are many "big" languages where there is a lot of complication
in the language itself. Certainly C++ is a "big" language, but it is
not the only one. Hands up all Python programmers who understand
metaclasses, slots, decorators, and generators?

2. For most programming languages, the standard library is an integral
part of the system. There is not a huge difference between knowing only
part of the core language, and knowing only part of the core libraries.

>
>> I don't think that is going to be your biggest problem in interviews,
>> judging from your posts here. Cheer up a bit, and try to look at the
>> positive sides of programming - that will make the difference.
>
> Don't patronise me you arrogant prick.

And there we go - a prime example! Add it to your abuse, insults and
accusations of lying in another recent thread.

> I was probably already programming while
> you were still learning to spell "computer".

Possibly, possibly not. My first forays into programming were 35 years
ago - /before/ I could spell "computer". I am certainly not the oldest
around here, and there are many with more than my 25 years of
professional programming experience. But I am also far from the
youngest. And I have been around for long enough to know that it is
very rarely helpful to guess about people - judge people and their
knowledge from their posts, not based on random insults.

> I respond in kind to the sort of
> replies I get.
>

That is not how it reads from where I am standing.

But enough of this - I would prefer not to get bogged down in a slagging
match. I'd rather go back to the technical discussion on <=>.

[Bo Persson]

On 2018-05-09 10:26, bol...@cylonHQ.com wrote:
> On Wed, 09 May 2018 09:04:26 +0200
> David Brown <david...@hesbynett.no> wrote:

That also gives you a chance to impress the interviewer:

"Is that part of Appendix D? I don't use that stuff much."


Bo Persson

[Ian Collins]

On 05/09/2018 10:39 PM, David Brown wrote:
> On 09/05/18 11:45, bol...@cylonHQ.com wrote:
>>
>> I don't know how it works with templates but I'm not sure why its use is
>> preferable to the isnan() function which has been around for decades (I assume
>> thats all its checking for).
>
> Why are you assuming anything here?

There be trolls in them woods...

--
Ian.

[David Brown]

I am giving him the benefit of the doubt here - I think he genuinely
thought it was an operator for checking that two expressions are
comparable. If that had been true, then I would have agreed with him
that it is unhelpful to add a new language operator for something as
rarely useful as that.

But it would not have taken long for a web search to find out if this
were the case.

[bol...@cylonhq.com]

On Wed, 09 May 2018 12:39:19 +0200
David Brown <david...@hesbynett.no> wrote:

>On 09/05/18 11:45, bol...@cylonHQ.com wrote:
>> I don't know how it works with templates but I'm not sure why its use is
>> preferable to the isnan() function which has been around for decades (I
>assume
>> thats all its checking for).
>
>Why are you assuming anything here? I /told/ you how it works - and it
>has no relation to isnan() at all. Perhaps you imagine that "a <=> b"
>simply means "(a < b) || (a == b) || (a > b)" - if so, you are totally
>and completely wrong. Read what I wrote earlier in this thread, or look
>it up.
>>

So in other words its a pseudo operator that does nothing in itself. And
they could think of a better way to add the functionality than this?

>> I've never even heard of it.
>
><https://en.cppreference.com/w/cpp/utility/optional>
>
>If you want to know about its implementation, google is your friend.

Looking at its supposed use case I couldn't even care less about using it,
never mind how its implemented.

>C++ always has a baggage of backwards compatibility. And 40 years ago,
>people failed to predict how it would be used now - what a surprise!

Given that there's nothing you can't do with C or even assembler, I fail to see
what its used for having any bearing on the language syntax. The syntax is
meant to make programming simpler and less hassle, not magic up completely new
paradigms. I have by doubts this is the intention of the C++ committee any more.

>Improvements in the C++ language have meant that many things that used
>to be complicated are now much simpler. A fine example is the "Safe
>boolean idiom". Prior to C++11, this was a really ugly mess, and it

The safe boolean idiom to me seems like another solution looking for a problem.
If you don't want to compare objects of 2 classes then don't. Code doesn't
write itself.

>> No, it isn't. While its usually impossible for someone to learn all APIs and
>> libraries of a language, most languages syntax can be learnt in their
>entirely.
>> C++ is the exception to the rule and I know of a couple of good developers
>> who've dropped the language because of the constant addition of unnecessary
>> fat to the language that only seems to appeal to language geeks and is of
>> little to no relevance to application programmers who make up 99.9% of C++'s
>> user base.
>
>1. There are many "big" languages where there is a lot of complication
>in the language itself. Certainly C++ is a "big" language, but it is
>not the only one. Hands up all Python programmers who understand
>metaclasses, slots, decorators, and generators?

Python syntax is a minnow compared to C++ and its another language I have to
keep up with in my job.

>2. For most programming languages, the standard library is an integral
>part of the system. There is not a huge difference between knowing only
>part of the core language, and knowing only part of the core libraries.

Given how different win32 and the posix API are I'm not sure you'll convince
many than knowing the standard library is the same as knowing the language.

>> Don't patronise me you arrogant prick.
>
>And there we go - a prime example! Add it to your abuse, insults and
>accusations of lying in another recent thread.

But being patronising is ok is it?

>> I was probably already programming while
>> you were still learning to spell "computer".
>
>Possibly, possibly not. My first forays into programming were 35 years
>ago - /before/ I could spell "computer". I am certainly not the oldest

We'll take that possibly and change it to a definately then.

>youngest. And I have been around for long enough to know that it is
>very rarely helpful to guess about people - judge people and their

Educated guess.

>That is not how it reads from where I am standing.

Well you're standing on shaky ground anyway.

[bol...@cylonhq.com]

On Wed, 9 May 2018 12:51:32 +0200
Bo Persson <b...@gmb.dk> wrote:
>On 2018-05-09 10:26, bol...@cylonHQ.com wrote:
>> On Wed, 09 May 2018 09:04:26 +0200
>> David Brown <david...@hesbynett.no> wrote:

I might try that next time ;)

[David Brown]

On 09/05/18 13:46, bol...@cylonHQ.com wrote:
> On Wed, 09 May 2018 12:39:19 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/05/18 11:45, bol...@cylonHQ.com wrote:
>>> I don't know how it works with templates but I'm not sure why its use is
>>> preferable to the isnan() function which has been around for decades (I
>> assume
>>> thats all its checking for).
>>
>> Why are you assuming anything here? I /told/ you how it works - and it
>> has no relation to isnan() at all. Perhaps you imagine that "a <=> b"
>> simply means "(a < b) || (a == b) || (a > b)" - if so, you are totally
>> and completely wrong. Read what I wrote earlier in this thread, or look
>> it up.
>>>
>
> So in other words its a pseudo operator that does nothing in itself. And
> they could think of a better way to add the functionality than this?
>

As I said, its primary use is for class and template definitions, not
for application code. Its purpose is to let you write ordered classes
with minimal code.

Suppose you want a "Date" class with comparison operators. With current
C++, you'd be writing something like:

class Date {
int year;
int month;
int day;
public:
friend bool operator==(const Date& a, const Date& b)
{ return (a.year == b.year) && (a.month == b.month) &&
(a.day == b.day); }

friend bool operator<(const Date& a, const Date& b)
{ return (a.year < b.year) ||
((a.year == b.year) && (a.month <= b.month)) ||
((a.year == b.year) && (a.month == b.month) &&
(a.day < b.day)); }

(a.day == b.day); }

friend bool operator!=(const Date& a, const Date& b)
{ return !(a == b); }

friend bool operator<=(const Date& a, const Date& b)
{ return (a <= b) || (a == b); }

friend bool operator>(const Date& a, const Date& b)
{ return !(a <= b); }

friend bool operator>=(const Date& a, const Date& b)
{ return !(a < b); }
}

With C++20, you'd write:

class Date {
int year;
int month;
int day;
public:
auto operator<=>(const Point&) const = default;
}

Tell me, which do you think is easier? And if you want a more
sophisticated comparison, you can have a custom <=> operator method and
then all the other comparisons are still generated automatically.

It is a good idea, and will give simpler code with less risk of errors.
Class /users/ are rarely going to see it - it is for class and library
writers.

>>> I've never even heard of it.
>>
>> <https://en.cppreference.com/w/cpp/utility/optional>
>>
>> If you want to know about its implementation, google is your friend.
>
> Looking at its supposed use case I couldn't even care less about using it,
> never mind how its implemented.

Fair enough, I suppose. Other people think it is a useful class. But
that will depend on the kind of code you work on.

>
>> C++ always has a baggage of backwards compatibility. And 40 years ago,
>> people failed to predict how it would be used now - what a surprise!
>
> Given that there's nothing you can't do with C or even assembler, I fail to see
> what its used for having any bearing on the language syntax. The syntax is
> meant to make programming simpler and less hassle, not magic up completely new
> paradigms. I have by doubts this is the intention of the C++ committee any more.
>

That is a very strange claim. Why should syntax /not/ make new
programming paradigms possible? This is, in fact, what has been
happening with C++ through the ages. It started with an imperative
programming base, and gained support for object oriented programming.
Templates added generic programming - and this aspect has been getting
more and more support for each generation of C++. Lambdas added
features from functional programming, const_expr improved compile-time
programming, concepts give another layer of type programming,
metaclasses (probably C++23 rather than C++20, I think) will give
another paradigm. If you don't like this flexibility, C++ is not the
language for you.

Secondly, I have explained a number of times now this particular example
of the <=> operator makes coding simpler and less hassle. So do many of
the other recent developments in C++.

You would do well to look at the changes that have come with C++11,
C++14 and C++17, and the proposed ones for C++20, before making spurious
and unjustified claims about them. I expect there is quite a lot there
that you won't see the use of - no one is expected to need it all. But
I am sure you will find cases where you /can/ simplify your coding.

>> Improvements in the C++ language have meant that many things that used
>> to be complicated are now much simpler. A fine example is the "Safe
>> boolean idiom". Prior to C++11, this was a really ugly mess, and it
>
> The safe boolean idiom to me seems like another solution looking for a problem.
> If you don't want to compare objects of 2 classes then don't. Code doesn't
> write itself.

Do you know what the "safe boolean idiom" actually /is/, and where it is
used? It comes from very real coding situations, and lets you write
simple tests like "if (p) foo(*p);" that have been idiomatic since the
birth of C - but it lets you do it with your own classes. The idiom,
and the myriad of web sites showing implementations, are commonly used -
but because they are ugly and hard to write (but very simple to use), it
is mostly only in bigger and more advanced class libraries that you saw
it. The simple addition of explicit conversion operators in C++11 made
safe booleans quick and easy for everyone. (It also has many other
uses, and generally gives safer and clearer code.)

>
>>> No, it isn't. While its usually impossible for someone to learn all APIs and
>>> libraries of a language, most languages syntax can be learnt in their
>> entirely.
>>> C++ is the exception to the rule and I know of a couple of good developers
>>> who've dropped the language because of the constant addition of unnecessary
>>> fat to the language that only seems to appeal to language geeks and is of
>>> little to no relevance to application programmers who make up 99.9% of C++'s
>>> user base.
>>
>> 1. There are many "big" languages where there is a lot of complication
>> in the language itself. Certainly C++ is a "big" language, but it is
>> not the only one. Hands up all Python programmers who understand
>> metaclasses, slots, decorators, and generators?
>
> Python syntax is a minnow compared to C++ and its another language I have to
> keep up with in my job.
>

I'll take that as a "hands down" on knowing all about Python syntax.
(Again, there is nothing wrong with that - you don't need to know all of
Python syntax any more than you need to know all of C++ syntax.)

>> 2. For most programming languages, the standard library is an integral
>> part of the system. There is not a huge difference between knowing only
>> part of the core language, and knowing only part of the core libraries.
>
> Given how different win32 and the posix API are I'm not sure you'll convince
> many than knowing the standard library is the same as knowing the language.
>

Neither Win32 nor POSIX are language standard libraries.

<snip>

[Juha Nieminen]

bol...@cylonhq.com wrote:
> Ever get the feeling the commitee has run out of useful things to add to
> the language and are now simply justifying their own existence?

Many of the changes are made to make it easier to write programs with less
code. You can, for instance, create libraries that can be used more easily
and by writing less code, without compromizing efficiency (and in some cases
even increasing efficiency).

Many of the new features add support for things that were awkward, laborious
or even impossible previously. Many of these features are on the compiler
level (rather than the runtime level).

As an example, std::tuple would have been very difficult (if not impossible)
in C++98, but now it's possible. Is the internal implementation of std::tuple
very complex? It certainly is. However, its *usage* is extraordinarily
simple, and can be quite handy. Overall, variadic templates, as well as
initializer lists, make many things now possible that were very hard
previously. Most especially, they make it possible to create libraries
that are much easier to use, than before. (C++17 makes variadic templates
even more flexible than before. For instance, you now don't need to
necessarily specify the template types for std::tuple, nor to use a
separate function like std::make_tuple, because the types are deduced
automatically.)

Many of the features up to C++17 are so handy that it would be a real
pain to go back to C++98.

[bol...@cylonhq.com]

On Wed, 09 May 2018 14:49:43 +0200
David Brown <david...@hesbynett.no> wrote:

>On 09/05/18 13:46, bol...@cylonHQ.com wrote:
>public:
> auto operator<=>(const Point&) const = default;
>}
>
>Tell me, which do you think is easier? And if you want a more

It might be simple, but its also non standard having an operator that
implicitly creates overloads for other operators. Its just another in a long
line of hacks such as "= 0" for pure virtuals instead of using keywords such
as "using std::overloads;" or something similar.

And even if they didn't create a keyword would the extra few lines of:
auto operator<(const Point&) const = default;
auto operator=(const Point&) const = default;
auto operator>(const Point&) const = default;
etc

really be so onorous? And if you need to do it multiple times just use a
macro. Thats what they're for.

>Templates added generic programming - and this aspect has been getting
>more and more support for each generation of C++. Lambdas added
>features from functional programming, const_expr improved compile-time

Its things like lamdas I'm talking about. They bring nothing to the table,
they're just syntactic sugar that IMO lead to code thats a lot messier than
just passing a function pointer. But for some reason some people seem to be in
love with nested functions. There are plenty of other examples.

>programming, concepts give another layer of type programming,
>metaclasses (probably C++23 rather than C++20, I think) will give

Hopefully by 2023 I'll be out of this game and won't have to care about this
race to incomprehensibility any longer.

>another paradigm. If you don't like this flexibility, C++ is not the
>language for you.

I don't have much of a choice frankly.

>> The safe boolean idiom to me seems like another solution looking for a
>problem.
>> If you don't want to compare objects of 2 classes then don't. Code doesn't
>> write itself.
>
>Do you know what the "safe boolean idiom" actually /is/, and where it is
>used? It comes from very real coding situations, and lets you write

Well I know what I read online. If I got the wrong end of the stick then I
guess thats too bad, I honestly don't care.

>> Python syntax is a minnow compared to C++ and its another language I have to
>> keep up with in my job.
>>
>
>I'll take that as a "hands down" on knowing all about Python syntax.

I never claimed I did. For my job I have to know C, C++, python, javascript,
SQL , MongoDB a smattering of x86 assembler and java and of course all the
standard unix languages such as awk, bash script and bc. On top of that I need
to know the posix API inside out, the STL, the common python libraries and
whatever brainfart the people "designing" javascript have come up with this
week. Oh, and tensorflow because machine learning is where its at. Apparently.

And at my age I don't give a flying feck about of it. They're tools to get
the job done and for me to earn a salary.

>> Given how different win32 and the posix API are I'm not sure you'll convince
>> many than knowing the standard library is the same as knowing the language.
>>
>
>Neither Win32 nor POSIX are language standard libraries.

Define standard. win32 is the standard windows C API and posix the standard
unix C API. Try writing anything useful in C/C++ on those OS's without them.

[Richard]

[Please do not mail me a copy of your followup]

bol...@cylonHQ.com spake the secret code
<pcubbi$1bf$1...@gioia.aioe.org> thusly:

>Ever get the feeling the commitee has run out of useful things to add to
>the language and are now simply justifying their own existence?

No.

Maybe you would get that impression if all you know is what you read
on usenet. Try watching the videos on these topics by the very same
people that are writing the standards proposal.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[woodb...@gmail.com]

I prefer Duckduckgo -- https://duckduckgo.com
. The Wall Street Journal has an article today about how
many good alternatives there are to Google:

https://www.wsj.com/articles/how-to-keep-google-from-owning-your-online-life-1525795372

. I wasn't able to read much of the article though as I'm
not a subscriber to that site.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Paavo Helde]

On 9.05.2018 18:12, bol...@cylonHQ.com wrote:
> On Wed, 09 May 2018 14:49:43 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 09/05/18 13:46, bol...@cylonHQ.com wrote:
>> public:
>> auto operator<=>(const Point&) const = default;
>> }
>>
>> Tell me, which do you think is easier? And if you want a more
>
> It might be simple, but its also non standard having an operator that
> implicitly creates overloads for other operators.

If it's in the C++ standard, then it's standard ;-)

> Its just another in a long
> line of hacks such as "= 0" for pure virtuals instead of using keywords such
> as "using std::overloads;" or something similar.
>
> And even if they didn't create a keyword would the extra few lines of:
> auto operator<(const Point&) const = default;
> auto operator=(const Point&) const = default;
> auto operator>(const Point&) const = default;
> etc
>
> really be so onorous? And if you need to do it multiple times just use a
> macro. Thats what they're for.

Nope, macros are a workaround that should be used as little as possible
in C++.

Replicating an interface like that will be covered by the C++ concepts
mechanism if I am not mistaken. If so, the interface-creating effect of
<==> indeed seems like an unneeded duplication.

>
>> Templates added generic programming - and this aspect has been getting
>> more and more support for each generation of C++. Lambdas added
>> features from functional programming, const_expr improved compile-time
>
> Its things like lamdas I'm talking about. They bring nothing to the table,
> they're just syntactic sugar that IMO lead to code thats a lot messier than
> just passing a function pointer. But for some reason some people seem to be in
> love with nested functions. There are plenty of other examples.

If lambda was equivalent to a function pointer then of course there
would not be much point in using it. However, currently it replaces a
lot of unneeded boilerplate code related to forwarding all the bound
variables and maybe also creating a helper class for clarity.

>> I'll take that as a "hands down" on knowing all about Python syntax.
>
> I never claimed I did. For my job I have to know C, C++, python, javascript,
> SQL , MongoDB a smattering of x86 assembler and java and of course all the
> standard unix languages such as awk, bash script and bc. On top of that I need
> to know the posix API inside out, the STL, the common python libraries and
> whatever brainfart the people "designing" javascript have come up with this
> week. Oh, and tensorflow because machine learning is where its at. Apparently.

For curiosity, what kind of job that is? BTW, division of labor was
invented already many thousands of years ago.

I understand that it is hard or maybe impossible to know all these
languages in deep, but this is no reason for being proud about your
ignorance and display it here in this group.

>
> And at my age I don't give a flying feck about of it. They're tools to get
> the job done and for me to earn a salary.
>
>>> Given how different win32 and the posix API are I'm not sure you'll convince
>>> many than knowing the standard library is the same as knowing the language.
>>>
>>
>> Neither Win32 nor POSIX are language standard libraries.
>
> Define standard.

C++ standard is defined by ISO/IEC 14882:2017
(https://www.iso.org/standard/68564.html).

> win32 is the standard windows C API and posix the standard
> unix C API. Try writing anything useful in C/C++ on those OS's without them.

This is because you are not familiar with newer C++ standards. Many
areas which used to require third-party libraries or OS API-s are now
part of the C++ standard and can be used in portable code. GUI
programming is the main missing part and for that you should use a
portable third-party library.

[David Brown]

You are mistaken :-) (As far as I know - correct me if I'm wrong here).

Concepts add restrictions and limitations, but they won't generate code
like this. Metaclasses will, but they are further off in the future.

Concepts /could/ be used here to some extent. For example, if there
were a <=> operator defined but there was no automatic generation of the
additional comparisons by default, then you could have:

template<typename T>
concept Space_strong_ordering = requires(T a, T b) {
{ a <=> b } -> std::strong_ordering;
};

template<Space_strong_ordering T>
bool operator<=(const T& a, const T& b)
{ return (a <=> b) <= 0; }

// And so on for the other comparisons

However, that would mean you would have these comparisons for anything
that supported the spaceship operator, instead of being able to disable
them when you don't want them or easily override them for specialisation.

And you still need the spaceship operator itself.

>
>>
>>> Templates added generic programming - and this aspect has been getting
>>> more and more support for each generation of C++.  Lambdas added
>>> features from functional programming, const_expr improved compile-time
>>
>> Its things like lamdas I'm talking about. They bring nothing to the
>> table,
>> they're just syntactic sugar that IMO lead to code thats a lot messier
>> than
>> just passing a function pointer. But for some reason some people seem
>> to be in
>> love with nested functions. There are plenty of other examples.
>
> If lambda was equivalent to a function pointer then of course there
> would not be much point in using it. However, currently it replaces a
> lot of unneeded boilerplate code related to forwarding all the bound
> variables and maybe also creating a helper class for clarity.

Indeed - lambdas are a lot more than just a function pointer. You /can/
get the functionality via functor objects, but as you say there is a lot
of extra code need that lambdas simplify.

Programming with lambdas often seems very strange when you are
unfamiliar with them, and for those who don't use them, it can be hard
to understand their benefits. But once you have got the hang of them,
they can be very handy for putting code at the point you want, not
spread out in the source code file.

[Alf P. Steinbach]

On 09.05.2018 23:24, David Brown wrote:
> On 09/05/18 19:29, Paavo Helde wrote:
>> On 9.05.2018 18:12, bol...@cylonHQ.com wrote:
>>
>> Replicating an interface like that will be covered by the C++ concepts
>> mechanism if I am not mistaken. If so, the interface-creating effect
>> of <==> indeed seems like an unneeded duplication.
>
> You are mistaken :-) (As far as I know - correct me if I'm wrong here).
>
> Concepts add restrictions and limitations, but they won't generate code
> like this.  Metaclasses will, but they are further off in the future.

Once seen it's trivial to generate the relational operators via a CRTP
mix-in class.

AFAIK that was the original use case for the Barton-Nackman trick.

For the language lawyer there's stuff to dig into here, because the
language evolved to completely different rules about "namespace
injection", but in a way that would preserve existing BN-trick code. At
the time of their "Scientific programming" (IIRC) book the operators
were found in the enclosing namespace, while today they're found via
argument dependent lookup.


Cheers!,

- Alf

[Rudi Cilibrasi]

Sutter et al's paper explains the motivation and advantages pretty well for the consistent comparison operator:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf

Cheers

Rudi

[Paavo Helde]

On 10.05.2018 0:24, David Brown wrote:
> On 09/05/18 19:29, Paavo Helde wrote:

>> Replicating an interface like that will be covered by the C++ concepts
>> mechanism if I am not mistaken. If so, the interface-creating effect
>> of <==> indeed seems like an unneeded duplication.
>
> You are mistaken :-) (As far as I know - correct me if I'm wrong here).
>
> Concepts add restrictions and limitations, but they won't generate code
> like this. Metaclasses will, but they are further off in the future.

Right, I must have had metaclasses in mind.

While CRTP does work for this task, as Alf mentioned, it would not make
the code any clearer. The proposed metaclasses syntax seems more
straightforward.

[bol...@cylonhq.com]

On Wed, 9 May 2018 16:28:20 +0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>bol...@cylonHQ.com spake the secret code
><pcubbi$1bf$1...@gioia.aioe.org> thusly:
>
>>Ever get the feeling the commitee has run out of useful things to add to
>>the language and are now simply justifying their own existence?
>
>No.
>
>Maybe you would get that impression if all you know is what you read
>on usenet. Try watching the videos on these topics by the very same
>people that are writing the standards proposal.

Next time I have insomnia I'll give them a look.

[bol...@cylonhq.com]

On Wed, 09 May 2018 20:29:14 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 9.05.2018 18:12, bol...@cylonHQ.com wrote:
>> It might be simple, but its also non standard having an operator that
>> implicitly creates overloads for other operators.
>
>If it's in the C++ standard, then it's standard ;-)

Well yes, I suppose, but you know what I mean :)

>> really be so onorous? And if you need to do it multiple times just use a
>> macro. Thats what they're for.
>
>Nope, macros are a workaround that should be used as little as possible
>in C++.

They do the job. In what sense is that a workaround? Plus they're absolutely
essential if you're writing portable code that does more than just Hello World.

>If lambda was equivalent to a function pointer then of course there
>would not be much point in using it. However, currently it replaces a
>lot of unneeded boilerplate code related to forwarding all the bound
>variables and maybe also creating a helper class for clarity.

I've seen a lot of code with lambda functions in, clarity isn't the word I'd
use for any of it. Code salad maybe.

>For curiosity, what kind of job that is? BTW, division of labor was
>invented already many thousands of years ago.

A job where the other devs were let go and I'm the only one left. And we also
have no sys admin at the moment. Guess who gets to do that job too? Devops is
the titre du jour for that at the moment. I'd give it another name thats a bit
less polite.

>I understand that it is hard or maybe impossible to know all these
>languages in deep, but this is no reason for being proud about your
>ignorance and display it here in this group.

Disagreeing with the groupthink is not ignorance. And when the day comes that
I'm unable to write some clean code using what knowledge I have then maybe I'll
dive into the latest standards. Up until now I've barely had any use for
anything from the 2011 standard apart from autos and initialiser lists never
mind beyond.

> > win32 is the standard windows C API and posix the standard
>> unix C API. Try writing anything useful in C/C++ on those OS's without them.
>
>This is because you are not familiar with newer C++ standards. Many
>areas which used to require third-party libraries or OS API-s are now
>part of the C++ standard and can be used in portable code. GUI

Not enough to be particularly useful for systems programming, and the C++
standard threading library leaves a lot to be desired compared to pthreads
though I guess its useful for portability. Also they seem to have been aiming
at Windows which prefers threads over multi process (mainly since it can't do
process spawning in any sane way) as AFAIK there's little sign of standard
support for the latter on the horizon.

>programming is the main missing part and for that you should use a
>portable third-party library.

Learnt Xlib back in the 90s, wrote some games. Even wrote an X window manager
about 15 years ago.

[K. Frank]

Hi Boltar!

A quick response to your comment about threads -- not about the
original <=> topic:

On Thursday, May 10, 2018 at 4:35:52 AM UTC-4, bol...@cylonhq.com wrote:
> ...
> ... the C++

> standard threading library leaves a lot to be desired compared to pthreads
> though I guess its useful for portability.

> ...

What do you find that pthreads does for you that is not comparably
straightforward using std::thread, etc?

I like pthreads and think it is quite good. (I grew up on pthreads,
so to speak.) But I also like std::thread, and it, too, seems
quite good to me.

Sure, std::thread uses classes that you call member functions on,
rather than passing pthread_t's around to free functions, but it
has very much the same flavor as pthreads, and the basic building
blocks of std::thread and pthreads map pretty cleanly to one another.

What's std::thread missing that it "leaves a lot to be desired?"


Happy Multi-Threaded Hacking!


K. Frank

[bol...@cylonhq.com]

On Thu, 10 May 2018 12:45:58 -0700 (PDT)
"K. Frank" <kfran...@gmail.com> wrote:
>Hi Boltar!
>
>A quick response to your comment about threads -- not about the
>original <=> topic:
>
>On Thursday, May 10, 2018 at 4:35:52 AM UTC-4, bol...@cylonhq.com wrote:
>> ...
>> ... the C++
>> standard threading library leaves a lot to be desired compared to pthreads
>> though I guess its useful for portability.
>> ...
>
>What do you find that pthreads does for you that is not comparably
>straightforward using std::thread, etc?

I gave up using threads a long time back and went back to multiprocess, but
off the top of my head there is no equivalent of pthread_get/setspecific, there
can be issues with C libraries that use pthreads and (a minor point), you can't
use a c++ mutex in shared memory.

[Paavo Helde]

On 11.05.2018 12:27, bol...@cylonHQ.com wrote:
> On Thu, 10 May 2018 12:45:58 -0700 (PDT)
> "K. Frank" <kfran...@gmail.com> wrote:
>> Hi Boltar!
>>
>> A quick response to your comment about threads -- not about the
>> original <=> topic:
>>
>> On Thursday, May 10, 2018 at 4:35:52 AM UTC-4, bol...@cylonhq.com wrote:
>>> ...
>>> ... the C++
>>> standard threading library leaves a lot to be desired compared to pthreads
>>> though I guess its useful for portability.
>>> ...
>>
>> What do you find that pthreads does for you that is not comparably
>> straightforward using std::thread, etc?
>
> I gave up using threads a long time back and went back to multiprocess, but
> off the top of my head there is no equivalent of pthread_get/setspecific, there

Is this the same as thread_local variables? FYI, thread_local is a C++
keyword since 2011.

[Jorgen Grahn]

Although it doesn't fall under "a lot to be desired". there's always
good old inertia. People tend to be familiar with pthreads, have
documentation and books that cover it, they may be using it in C, and
so on. And cross-platform aspects aren't relevant to most software.

For these kinds of reasons, I'm no big fan of pulling system-specific
stuff in under the language umbrella. (I'd be more inclined to use the
higher-level concurrency stuff in C++11.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[woodb...@gmail.com]

There's no shortage of stuff for std::junkpile. Some of it
gets used for awhile, but then is discarded.

[Jorgen Grahn]

For the record, I don't agree with the junkpile metaphor. C++98 was a
success from my point of view, and we don't know yet about C++11 and
later.

But neither am I going to jump on anything new that gets standardized
as part of C++, when I already have a mechanism that I know, and
that's already standardized on the platforms I care about.

[james...@alumni.caltech.edu]

On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
> On Wed, 09 May 2018 14:49:43 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 09/05/18 13:46, bol...@cylonHQ.com wrote:

...

> >> Given how different win32 and the posix API are I'm not sure you'll convince
> >> many than knowing the standard library is the same as knowing the language.
> >>
> >
> >Neither Win32 nor POSIX are language standard libraries.
>
> Define standard. win32 is the standard windows C API and posix the standard

> unix C API. ...

The key issue isn't the meaning of "standard", but the meaning of
"language". In context, I would assume that "language standard
libraries" refers to libraries whose existence is mandated by a
language standard, such as the C and C++ standards, both of which
mandate the existence of libraries. With that interpretation, neither
the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
understand the term "language" to play in that context, or did you
simply ignore it?

> ... Try writing anything useful in C/C++ on those OS's without them.

I've tried it - it's not very difficult. I've spent most of the last 22
years writing C code that makes little or no use of POSIX-specific
features (because it has no need to) or Win32 (because it wasn't being
developed on Windows systems), and much of the last 6 years doing the
same with C++ code. Usefulness is always debatable, but my employers
have paid me a fairly decent salary for producing such code, which
mplies that they, at least, found it useful.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnpfe0a5.31...@frailea.sa.invalid> thusly:

>But neither am I going to jump on anything new that gets standardized
>as part of C++, when I already have a mechanism that I know, and
>that's already standardized on the platforms I care about.

For most library features, they've evolved from features already
implemented as libraries and having had widespread use. Many C++11
(and later) library editions were migrations from boost, such as
shared_ptr, thread, and filesystem.

This is one of the things that disturbs me about the 2D graphics
effort; they are creating a proposal from something without having
widespread use of it in the proposed form.

[bol...@cylonhq.com]

On Sat, 12 May 2018 13:51:58 -0700 (PDT)
james...@alumni.caltech.edu wrote:
>On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>The key issue isn't the meaning of "standard", but the meaning of
>"language". In context, I would assume that "language standard
>libraries" refers to libraries whose existence is mandated by a
>language standard, such as the C and C++ standards, both of which
>mandate the existence of libraries. With that interpretation, neither
>the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>understand the term "language" to play in that context, or did you
>simply ignore it?

The posix API libraries come with every C/C++ compiler installed on every
unix system since god knows when. IMO that makes them standard.

>> ... Try writing anything useful in C/C++ on those OS's without them.
>
>I've tried it - it's not very difficult. I've spent most of the last 22
>years writing C code that makes little or no use of POSIX-specific
>features (because it has no need to) or Win32 (because it wasn't being

So in other words you have written anything particularly complex since you
won't have created or read directories or other filesystem operations more
complex than file I/O, you won't have written any networking code, any code
that involves multi process or multi threading , any memory management more
complex than malloc or new, regular expressions, signals pipes, timing blah
blah blah.

But I'm sure it was a fantastic Hello World program that you ended up with.

[David Brown]

On 14/05/18 10:34, bol...@cylonHQ.com wrote:
> On Sat, 12 May 2018 13:51:58 -0700 (PDT)
> james...@alumni.caltech.edu wrote:
>> On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>> The key issue isn't the meaning of "standard", but the meaning of
>> "language". In context, I would assume that "language standard
>> libraries" refers to libraries whose existence is mandated by a
>> language standard, such as the C and C++ standards, both of which
>> mandate the existence of libraries. With that interpretation, neither
>> the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>> understand the term "language" to play in that context, or did you
>> simply ignore it?
>
> The posix API libraries come with every C/C++ compiler installed on every
> unix system since god knows when. IMO that makes them standard.
>

What about every C and C++ compiler that is /not/ for a unix system?
There are a great many compilers targeting other systems than *nix -
most embedded systems have no use for Posix.

The Posix API is /a/ standard, certainly - it is just not part of the
C++ standard.

>>> ... Try writing anything useful in C/C++ on those OS's without them.
>>
>> I've tried it - it's not very difficult. I've spent most of the last 22
>> years writing C code that makes little or no use of POSIX-specific
>> features (because it has no need to) or Win32 (because it wasn't being
>
> So in other words you have written anything particularly complex since you
> won't have created or read directories or other filesystem operations more
> complex than file I/O, you won't have written any networking code, any code
> that involves multi process or multi threading , any memory management more
> complex than malloc or new, regular expressions, signals pipes, timing blah
> blah blah.
>
> But I'm sure it was a fantastic Hello World program that you ended up with.
>

Lots of people write code doing all sorts of things on *nix, Windows, or
other systems, without using the low-level systems-specific APIs
directly. People writing graphics programs in C++ on *nix will
typically use something like wxwidgets or QT, along with the standard
C++ libraries. They don't need to go near the Posix API in order to get
threads, locks, file access, memory, networking, or whatever else they
want - and as a bonus, they have a least a good step towards
cross-platform support. For non-graphics work, you could use the same
toolkits or one of a myriad of others.

Sure, the *nix ports of QT, wxwidgets, and other libraries may use Posix
calls in their implementation. But the /application/ code doesn't need
it - and it does not care how the functions are implemented.

[bol...@cylonhq.com]

On Mon, 14 May 2018 12:22:26 +0200
David Brown <david...@hesbynett.no> wrote:
>On 14/05/18 10:34, bol...@cylonHQ.com wrote:
>> On Sat, 12 May 2018 13:51:58 -0700 (PDT)
>> james...@alumni.caltech.edu wrote:
>>> On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>>> The key issue isn't the meaning of "standard", but the meaning of
>>> "language". In context, I would assume that "language standard
>>> libraries" refers to libraries whose existence is mandated by a
>>> language standard, such as the C and C++ standards, both of which
>>> mandate the existence of libraries. With that interpretation, neither
>>> the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>>> understand the term "language" to play in that context, or did you
>>> simply ignore it?
>>
>> The posix API libraries come with every C/C++ compiler installed on every
>> unix system since god knows when. IMO that makes them standard.
>>
>
>What about every C and C++ compiler that is /not/ for a unix system?
>There are a great many compilers targeting other systems than *nix -

There are certain libraries that are standard on certain systems is my point.

>> But I'm sure it was a fantastic Hello World program that you ended up with.
>>
>
>Lots of people write code doing all sorts of things on *nix, Windows, or
>other systems, without using the low-level systems-specific APIs
>directly. People writing graphics programs in C++ on *nix will
>typically use something like wxwidgets or QT, along with the standard
>C++ libraries. They don't need to go near the Posix API in order to get
>threads, locks, file access, memory, networking, or whatever else they

Sure, if they're lego brick programmers they'll use a load of bloated high
level APIs with the "networking" probably being some horrendous REST HTTP stack
which takes 10 to 100x the bandwidth of something proprietary written using
sockets code. But then those sorts of people usually end up gravitating towards
java, python or javascript in the end anyway.

>Sure, the *nix ports of QT, wxwidgets, and other libraries may use Posix
>calls in their implementation. But the /application/ code doesn't need
>it - and it does not care how the functions are implemented.

Depends what its doing.

[Paavo Helde]

On 14.05.2018 13:53, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 12:22:26 +0200
> David Brown <david...@hesbynett.no> wrote:
>
>> Lots of people write code doing all sorts of things on *nix, Windows, or
>> other systems, without using the low-level systems-specific APIs
>> directly. People writing graphics programs in C++ on *nix will
>> typically use something like wxwidgets or QT, along with the standard
>> C++ libraries. They don't need to go near the Posix API in order to get
>> threads, locks, file access, memory, networking, or whatever else they
>
> Sure, if they're lego brick programmers they'll use a load of bloated high
> level APIs with the "networking" probably being some horrendous REST HTTP stack
> which takes 10 to 100x the bandwidth of something proprietary written using
> sockets code. But then those sorts of people usually end up gravitating towards
> java, python or javascript in the end anyway.

I gather this means you have never heard about boost::asio either.

How about learning a bit about a topic before starting to berate it?

[David Brown]

On 14/05/18 12:53, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 12:22:26 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 14/05/18 10:34, bol...@cylonHQ.com wrote:
>>> On Sat, 12 May 2018 13:51:58 -0700 (PDT)
>>> james...@alumni.caltech.edu wrote:
>>>> On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>>>> The key issue isn't the meaning of "standard", but the meaning of
>>>> "language". In context, I would assume that "language standard
>>>> libraries" refers to libraries whose existence is mandated by a
>>>> language standard, such as the C and C++ standards, both of which
>>>> mandate the existence of libraries. With that interpretation, neither
>>>> the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>>>> understand the term "language" to play in that context, or did you
>>>> simply ignore it?
>>>
>>> The posix API libraries come with every C/C++ compiler installed on every
>>> unix system since god knows when. IMO that makes them standard.
>>>
>>
>> What about every C and C++ compiler that is /not/ for a unix system?
>> There are a great many compilers targeting other systems than *nix -
>
> There are certain libraries that are standard on certain systems is my point.

Yes, that much is true. It wasn't what you said, however. And it does
not mean that you /have/ to use these libraries for programming on those
systems - you certainly don't need to do so directly.

>
>>> But I'm sure it was a fantastic Hello World program that you ended up with.
>>>
>>
>> Lots of people write code doing all sorts of things on *nix, Windows, or
>> other systems, without using the low-level systems-specific APIs
>> directly. People writing graphics programs in C++ on *nix will
>> typically use something like wxwidgets or QT, along with the standard
>> C++ libraries. They don't need to go near the Posix API in order to get
>> threads, locks, file access, memory, networking, or whatever else they
>
> Sure, if they're lego brick programmers they'll use a load of bloated high
> level APIs with the "networking" probably being some horrendous REST HTTP stack
> which takes 10 to 100x the bandwidth of something proprietary written using
> sockets code. But then those sorts of people usually end up gravitating towards
> java, python or javascript in the end anyway.

And I suppose you think /real/ men use raw X api calls?

Some people don't like to reinvent wheels if they can avoid it.

[James Kuyper]

On 05/14/2018 04:34 AM, bol...@cylonHQ.com wrote:
> On Sat, 12 May 2018 13:51:58 -0700 (PDT)
> james...@alumni.caltech.edu wrote:
>> On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>> The key issue isn't the meaning of "standard", but the meaning of
>> "language". In context, I would assume that "language standard
>> libraries" refers to libraries whose existence is mandated by a
>> language standard, such as the C and C++ standards, both of which
>> mandate the existence of libraries. With that interpretation, neither
>> the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>> understand the term "language" to play in that context, or did you
>> simply ignore it?
>
> The posix API libraries come with every C/C++ compiler installed on every
> unix system since god knows when. IMO that makes them standard.

Well, of course:
"In the late 1980s, an open operating system standardization effort now
known as POSIX provided a common baseline for all operating systems;
IEEE based POSIX around the common structure of the major competing
variants of the Unix system, publishing the first POSIX standard in
1988. In the early 1990s, a separate but very similar effort was started
by an industry consortium, the Common Open Software Environment (COSE)
initiative, which eventually became the Single UNIX Specification (SUS)
administered by The Open Group. Starting in 1998, the Open Group and
IEEE started the Austin Group, to provide a common definition of POSIX
and the Single UNIX Specification, which, by 2008, had become the Open
Group Base Specification."
<https://en.wikipedia.org/wiki/Unix#Standards>

So it's not particularly odd that unix systems have POSIX API libraries.
And, as I said above, there's nothing wrong with calling the "Open Group
Base Specification" a standard. However, it's an OPERATING SYSTEM
standard. C and C++ have LANGUAGE standards, which is a very different
thing. There's plenty of implementations of C and C++, targeting
platforms that don't conform to the Open Group Base Specification, which
therefore do not provide POSIX API libraries. which doesn't prevent them
from fully conforming to the relevant LANGUAGE standard, because those
libraries are not LANGUAGE standard libraries. It's the distinction
between operating system standard libraries and language standard
libraries that you have refused to acknowledge. The meaning of
"standard" has nothing to do with what's wrong with your statements.

Also, you seem to have the connections between those standards somewhat
backwards. The current version of the Open Group Base Specification
describes a command line utility named C99 which "shall accept source
code conforming to the ISO C standard" (a requirement that is far less
constraining than it might appear to be - but I won't go into that).
Previous versions of the standard(s) called it C89, and the standard
explicitly promises that it will exist in future versions of the
standard with a name that reflects (in a currently unpredictable manner)
changes to the C standard.
Despite nominally having been unified, the "Open Group Base
Specification" has several varieties of optional features, and as a
result, has the following to say about c99:
"On systems providing POSIX Conformance (see XBD Conformance), c99 is
required only with the C-Language Development option; XSI-conformant
systems always provide c99."

Therefore, a system that conforms to the Open Group Base Specification,
but is not XSI-conformant, or which conforms to POSIX without the
C-Language Developement option, need NOT provide C99. And the Open Group
Base Specification doesn't even mention C++, so any C++ standard
libraries that you happen to find on a unix system are not POSIX API
libraries

>>> ... Try writing anything useful in C/C++ on those OS's without them.
>>
>> I've tried it - it's not very difficult. I've spent most of the last 22
>> years writing C code that makes little or no use of POSIX-specific
>> features (because it has no need to) or Win32 (because it wasn't being
>
> So in other words you have written anything particularly complex since you
> won't have created or read directories or other filesystem operations more
> complex than file I/O, you won't have written any networking code, any code
> that involves multi process or multi threading , any memory management more
> complex than malloc or new, regular expressions, signals pipes, timing blah
> blah blah.
>
> But I'm sure it was a fantastic Hello World program that you ended up with.

"They", not "it" - I'm not describing a single program, but many
different programs. I'm not sure "fantastic" would apply, but they do a
lot more than "Hello World". They run 24/7 on thousands of different
systems located in the Goddard Space Flight Center, processing data
transmitted to the ground that was collected by the MODIS instruments on
the Terra and Aqua satellites, and by the VIIRS instruments on the Suomi
NPP and NOAA-20 satellites. They read input files, reformat the data and
perform calculations based upon the data, writing the reformatted and
newly calculated data to output files. Portability of the files is
handled mainly by a third-party library that I'm required to use, which
is built on top of XDR. The directories are created and destroyed by the
production system. There's no GUI code, or indeed any kind of user
interface - the operators use a GUI to control the production system,
but my programs interact only with the production systems, through their
command lines, file I/O, and return status. There's no networking code,
no multi-processing or multi-threaded code. Text processing is
completely negligible and has no need of internationalization.

It's just pure data processing, for which I have no need (and no
permission!) to go outside the range of facilities provided by pure C or
C++ and POSIX. I'm explicitly prohibited from using large parts of the
POSIX API, so as to prevent my programs from interfering with use of
those same facilities by the production system. But it's an awful lot of
data processing.

I'm well aware of the existence of many other kinds of programming very
different from what I'm doing - but programming like what I'm doing is
still very much alive. My programs constitute only a small fraction of
all the programs that run under the production systems I described;
there's hundreds of other programs built to operate under the same
restrictions, written by thousands of other programmers, and there's
many other production systems all over the world that are similarly
designed. Were you aware of that fact?

[James Kuyper]

On 05/14/2018 06:53 AM, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 12:22:26 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 14/05/18 10:34, bol...@cylonHQ.com wrote:
>>> On Sat, 12 May 2018 13:51:58 -0700 (PDT)
>>> james...@alumni.caltech.edu wrote:
>>>> On Wednesday, May 9, 2018 at 11:12:27 AM UTC-4, bol...@cylonhq.com wrote:
>>>> The key issue isn't the meaning of "standard", but the meaning of
>>>> "language". In context, I would assume that "language standard
>>>> libraries" refers to libraries whose existence is mandated by a
>>>> language standard, such as the C and C++ standards, both of which
>>>> mandate the existence of libraries. With that interpretation, neither
>>>> the Win32 nor the POSIX APIs qualify. I'm curious - what role did you
>>>> understand the term "language" to play in that context, or did you
>>>> simply ignore it?
>>>
>>> The posix API libraries come with every C/C++ compiler installed on every
>>> unix system since god knows when. IMO that makes them standard.
>>>
>>
>> What about every C and C++ compiler that is /not/ for a unix system?
>> There are a great many compilers targeting other systems than *nix -
>
> There are certain libraries that are standard on certain systems is my point.

Then why did you respond to David Brown's statement of fact that
"Neither Win32 nor POSIX are language standard libraries." by saying

"Define standard. win32 is the standard windows C API and posix the

standard unix C API."? The fact that those are APIs defined by OS
standards in no way contradicts the fact that they are NOT libraries
defined by language standards. As I said before, the definition of
"standard" has nothing to do with why those APIs fail to qualify as
language standard libraries.

[bol...@cylonhq.com]

No, and I couldn't care less about it either. I avoid boost like a would a
fly covered turd on a path.

[bol...@cylonhq.com]

On Mon, 14 May 2018 13:50:55 +0200
David Brown <david...@hesbynett.no> wrote:

>On 14/05/18 12:53, bol...@cylonHQ.com wrote:
>> There are certain libraries that are standard on certain systems is my point.
>
>Yes, that much is true. It wasn't what you said, however. And it does
>not mean that you /have/ to use these libraries for programming on those
>systems - you certainly don't need to do so directly.

No, but if you want efficient code it usually helps. I'm not a fan of the
turtles all the way down style of programming. One reason I steer clear of java
if I can help it.

>And I suppose you think /real/ men use raw X api calls?

Well if the shoe fits... ;)

Actually I did write some games back in the day and if you want good
performance then its either Xlib or openGL.

>Some people don't like to reinvent wheels if they can avoid it.

You don't need to reinvent the wheel, its a case of a wheel usually sufficing
and being a better choice than a jet engine.

[bol...@cylonhq.com]

On Mon, 14 May 2018 08:46:58 -0400
James Kuyper <james...@alumni.caltech.edu> wrote:
>Base Specification" a standard. However, it's an OPERATING SYSTEM
>standard. C and C++ have LANGUAGE standards, which is a very different
>thing. There's plenty of implementations of C and C++, targeting
>platforms that don't conform to the Open Group Base Specification, which
>therefore do not provide POSIX API libraries. which doesn't prevent them
>from fully conforming to the relevant LANGUAGE standard, because those
>libraries are not LANGUAGE standard libraries. It's the distinction
>between operating system standard libraries and language standard
>libraries that you have refused to acknowledge. The meaning of
>"standard" has nothing to do with what's wrong with your statements.

Thats all well and good, except with C++ now providing a threading model its
stepped over the line from pure language to OS implementation. So IMO there's
nothing wrong with going the other way and saying that the Posix API is a C and
C++ standard library.

>C-Language Developement option, need NOT provide C99. And the Open Group
>Base Specification doesn't even mention C++, so any C++ standard
>libraries that you happen to find on a unix system are not POSIX API
>libraries

Well we'll have to agree to disagree on that. I fail to see any point in
arguing further.

>It's just pure data processing, for which I have no need (and no
>permission!) to go outside the range of facilities provided by pure C or
>C++ and POSIX. I'm explicitly prohibited from using large parts of the
>POSIX API, so as to prevent my programs from interfering with use of
>those same facilities by the production system. But it's an awful lot of
>data processing.

Why use a systems programming language for pure data processing? You'd be
better off with R, matlab or even fortran.

>designed. Were you aware of that fact?

Yes, and they don't tend to use C or C++.

[James Kuyper]

On 05/14/2018 09:44 AM, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 08:46:58 -0400
> James Kuyper <james...@alumni.caltech.edu> wrote:
>> Base Specification" a standard. However, it's an OPERATING SYSTEM
>> standard. C and C++ have LANGUAGE standards, which is a very different
>> thing. There's plenty of implementations of C and C++, targeting
>> platforms that don't conform to the Open Group Base Specification, which
>> therefore do not provide POSIX API libraries. which doesn't prevent them
>>from fully conforming to the relevant LANGUAGE standard, because those
>> libraries are not LANGUAGE standard libraries. It's the distinction
>> between operating system standard libraries and language standard
>> libraries that you have refused to acknowledge. The meaning of
>> "standard" has nothing to do with what's wrong with your statements.
>
> Thats all well and good, except with C++ now providing a threading model its
> stepped over the line from pure language to OS implementation. So IMO there's
> nothing wrong with going the other way and saying that the Posix API is a C and
> C++ standard library.

Other than the fact that neither the C standard nor the C++ standard has
anything to say about the POSIX API. I suppose you consider that a minor
detail, but it's completely inconsistent with what I mean when I call
something a "C standard library".

>> C-Language Developement option, need NOT provide C99. And the Open Group
>> Base Specification doesn't even mention C++, so any C++ standard
>> libraries that you happen to find on a unix system are not POSIX API
>> libraries
>
> Well we'll have to agree to disagree on that.

No we don't - all you have to do to identify a C++ library as being part
of the POSIX API is to identify the part of the POSIX standard that
provides specifications for that library. If there's no such part, we're
not merely in disagreement, you're simply wrong.

>> It's just pure data processing, for which I have no need (and no
>> permission!) to go outside the range of facilities provided by pure C or
>> C++ and POSIX. I'm explicitly prohibited from using large parts of the
>> POSIX API, so as to prevent my programs from interfering with use of
>> those same facilities by the production system. But it's an awful lot of
>> data processing.
>
> Why use a systems programming language for pure data processing? You'd be
> better off with R, matlab or even fortran.

I didn't make the decision, I was just hired by people who decided to
use C - but many of them were very familiar with Fortran (you could tell
by the way they wrote their C), and they still chose C over Fortran -
knowing both languages, I think it was a good decision. Our contract
with our client doesn't permit the other two languages you mention.

[David Brown]

On 14/05/18 15:34, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 13:50:55 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 14/05/18 12:53, bol...@cylonHQ.com wrote:
>>> There are certain libraries that are standard on certain systems is my point.
>>
>> Yes, that much is true. It wasn't what you said, however. And it does
>> not mean that you /have/ to use these libraries for programming on those
>> systems - you certainly don't need to do so directly.
>
> No, but if you want efficient code it usually helps. I'm not a fan of the
> turtles all the way down style of programming. One reason I steer clear of java
> if I can help it.

There is a happy medium to be found. Sometimes the balance is towards
maximum run-time efficiency (and therefore low-level calls, and
low-level languages), and sometimes towards maximum developer efficiency
(and therefore high-level calls and languages). My small-system
embedded usually minimise libraries or abstraction layers - my PC
programming is usually in Python using libraries like wxpython.

>
>> And I suppose you think /real/ men use raw X api calls?
>
> Well if the shoe fits... ;)
>
> Actually I did write some games back in the day and if you want good
> performance then its either Xlib or openGL.
>
>> Some people don't like to reinvent wheels if they can avoid it.
>
> You don't need to reinvent the wheel, its a case of a wheel usually sufficing
> and being a better choice than a jet engine.
>

There is nothing wrong with using Posix calls when you know they are
available and do the job. The point is that there is /also/ nothing
wrong with using libraries built at a higher level, if that is what is
best for the job.

[bol...@cylonhq.com]

On Mon, 14 May 2018 10:01:04 -0400
James Kuyper <james...@alumni.caltech.edu> wrote:
>On 05/14/2018 09:44 AM, bol...@cylonHQ.com wrote:
>> Thats all well and good, except with C++ now providing a threading model its
>> stepped over the line from pure language to OS implementation. So IMO there's
>> nothing wrong with going the other way and saying that the Posix API is a C
>and
>> C++ standard library.
>
>Other than the fact that neither the C standard nor the C++ standard has
>anything to say about the POSIX API. I suppose you consider that a minor
>detail, but it's completely inconsistent with what I mean when I call
>something a "C standard library".

There are official standards and then there are de-facto standards on certain
OS's. The latter as you well know is what I'm referring to. C or C++ on their
own with no library support other than the official language standards are
pretty useless unless you happen to know assembler.

>> Well we'll have to agree to disagree on that.
>
>No we don't - all you have to do to identify a C++ library as being part
>of the POSIX API is to identify the part of the POSIX standard that
>provides specifications for that library. If there's no such part, we're
>not merely in disagreement, you're simply wrong.

I'm not talking about any official C++ library being part of the posix standard,
I'm talking about the posix libraries being standard C++ libraries since C++
is a good enough superset of C to be able to use them without any issues.
The same would apply to win32 being a standard C/C++ library on windows.

[Scott Lurndal]

James Kuyper <james...@alumni.caltech.edu> writes:
>On 05/14/2018 09:44 AM, bol...@cylonHQ.com wrote:
>> On Mon, 14 May 2018 08:46:58 -0400
>> James Kuyper <james...@alumni.caltech.edu> wrote:
>>> Base Specification" a standard. However, it's an OPERATING SYSTEM
>>> standard. C and C++ have LANGUAGE standards, which is a very different
>>> thing. There's plenty of implementations of C and C++, targeting
>>> platforms that don't conform to the Open Group Base Specification, which
>>> therefore do not provide POSIX API libraries. which doesn't prevent them
>>>from fully conforming to the relevant LANGUAGE standard, because those
>>> libraries are not LANGUAGE standard libraries. It's the distinction
>>> between operating system standard libraries and language standard
>>> libraries that you have refused to acknowledge. The meaning of
>>> "standard" has nothing to do with what's wrong with your statements.
>>
>> Thats all well and good, except with C++ now providing a threading model its
>> stepped over the line from pure language to OS implementation. So IMO there's
>> nothing wrong with going the other way and saying that the Posix API is a C and
>> C++ standard library.
>
>Other than the fact that neither the C standard nor the C++ standard has
>anything to say about the POSIX API. I suppose you consider that a minor
>detail, but it's completely inconsistent with what I mean when I call
>something a "C standard library".

While understanding your point about "standard libraries", I'd point
out that the POSIX API, while not explicitly calling out C++ specific
bindings, understands that C++ is backwards compatible with C with respect
to the existing C bindings.

[Vir Campestris]

On 14/05/2018 09:34, bol...@cylonHQ.com wrote:
> The posix API libraries come with every C/C++ compiler installed on every
> unix system since god knows when. IMO that makes them standard.

I haven't seen a Unix system since %deity% knows when. And not all Linux
systems have the libraries - some are stripped down embedded systems.

For that matter I worked on Windows for many years - and Posix was never
more than vaguely interesting. The only real cross-platform stuff I met
was Java.

Andy

[James Kuyper]

On 05/14/2018 10:16 AM, bol...@cylonHQ.com wrote:
> On Mon, 14 May 2018 10:01:04 -0400
> James Kuyper <james...@alumni.caltech.edu> wrote:
>> On 05/14/2018 09:44 AM, bol...@cylonHQ.com wrote:
>>> Thats all well and good, except with C++ now providing a threading model its
>>> stepped over the line from pure language to OS implementation. So IMO there's
>>> nothing wrong with going the other way and saying that the Posix API is a C
>> and
>>> C++ standard library.
>>
>> Other than the fact that neither the C standard nor the C++ standard has
>> anything to say about the POSIX API. I suppose you consider that a minor
>> detail, but it's completely inconsistent with what I mean when I call
>> something a "C standard library".
>
> There are official standards and then there are de-facto standards on certain
> OS's. The latter as you well know is what I'm referring to.

No, I didn't know that's what you were referring to. When referring to a
defacto standard, you should say "de-facto standard library", not
"language standard library" or "C standard library" or "C++ standard
library" if you don't wish to be misunderstood. Until you clarified that
fact in this very message, I assumed that you were in fact under the
mis-apprehension that the C and C++ standards did have something to say
about the POSIX API. Given your posting history, that assumption didn't
strike me as particularly implausible.
Incidentally, the POSIX API is NOT a defacto standard, it's a de-jure
standard. It's just not a language standard, which was the original point.

> ... C or C++ on their

> own with no library support other than the official language standards are
> pretty useless unless you happen to know assembler.

I've made a career of using them (almost) precisely that way without the
use of assembler. The "almost" refers to the fact that most of the input
and output files from my programs are required to be in HDF4 or HDF5
format, and I'm required to use the C or C++ versions of the HDF
libraries <https://www.hdfgroup.org/> to read them. HDF shelters me from
needing to worry a lot about the difficulties of porting data from one
platform to another - but I doubt that dealing with such difficulties
was the main point of your comment.

>>> Well we'll have to agree to disagree on that.
>>
>> No we don't - all you have to do to identify a C++ library as being part
>> of the POSIX API is to identify the part of the POSIX standard that
>> provides specifications for that library. If there's no such part, we're
>> not merely in disagreement, you're simply wrong.
>
> I'm not talking about any official C++ library being part of the posix standard,
> I'm talking about the posix libraries being standard C++ libraries since C++
> is a good enough superset of C to be able to use them without any issues.

Perhaps - but "standard" isn't even remotely the right term to use to
express that concept. "C++ compatible libraries" would cover the concept
quite nicely.

[Richard]

[Please do not mail me a copy of your followup]

bol...@cylonHQ.com spake the secret code
<pdbhlr$1c4j$1...@gioia.aioe.org> thusly:

>The posix API libraries come with every C/C++ compiler installed on every
>unix system since god knows when. IMO that makes them standard.

Spoken like a true unix bigot.

[bol...@cylonhq.com]

On Mon, 14 May 2018 16:59:33 -0400
James Kuyper <james...@alumni.caltech.edu> wrote:
>On 05/14/2018 10:16 AM, bol...@cylonHQ.com wrote:
>> ... C or C++ on their
>> own with no library support other than the official language standards are
>> pretty useless unless you happen to know assembler.
>
>I've made a career of using them (almost) precisely that way without the
>use of assembler. The "almost" refers to the fact that most of the input
>and output files from my programs are required to be in HDF4 or HDF5
>format, and I'm required to use the C or C++ versions of the HDF
>libraries <https://www.hdfgroup.org/> to read them. HDF shelters me from
>needing to worry a lot about the difficulties of porting data from one
>platform to another - but I doubt that dealing with such difficulties
>was the main point of your comment.

And the HDF libraries are part of the official standard are they? Remove all
the parts of your program that use anything except the official standard
libraries then see how well they work.

[bol...@cylonhq.com]

On Mon, 14 May 2018 22:33:14 +0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>bol...@cylonHQ.com spake the secret code
><pdbhlr$1c4j$1...@gioia.aioe.org> thusly:
>
>>The posix API libraries come with every C/C++ compiler installed on every
>>unix system since god knows when. IMO that makes them standard.
>
>Spoken like a true unix bigot.

You can also use posix on Windows, though since the windows kernel is so
limited in certain areas (process spawing & control, IPC, full signal
handling) you'll only ever be using a subset.

[Ian Collins]

You don't have to now we have threading as part of the standard library....

--
Ian.

[bol...@cylonhq.com]

No sane programmer uses threading if multi process can get the job done just
as well. The only reason is so popular is because its the default parallel
programming mode in Windows which is historical baggage down to the fact that
Windows had to run with the primitive MMUs on the 8086 and 286 and it was
easier to implement threading and CMT than proper pre-emptive multi tasking.

[Ian Collins]

On 15/05/18 22:17, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 20:41:44 +1200
> Ian Collins <ian-...@hotmail.com> wrote:
>> On 15/05/18 20:26, bol...@cylonHQ.com wrote:
>>> On Mon, 14 May 2018 22:33:14 +0000 (UTC)
>>> legaliz...@mail.xmission.com (Richard) wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> bol...@cylonHQ.com spake the secret code
>>>> <pdbhlr$1c4j$1...@gioia.aioe.org> thusly:
>>>>
>>>>> The posix API libraries come with every C/C++ compiler installed on every
>>>>> unix system since god knows when. IMO that makes them standard.
>>>>
>>>> Spoken like a true unix bigot.
>>>
>>> You can also use posix on Windows, though since the windows kernel is so
>>> limited in certain areas (process spawing & control, IPC, full signal
>>> handling) you'll only ever be using a subset.
>>
>> You don't have to now we have threading as part of the standard library....
>
> No sane programmer uses threading if multi process can get the job done just
> as well.

Yeah right...

> The only reason is so popular is because its the default parallel
> programming mode in Windows

Nope. Threads were popular before windows was inflicted on an
unsuspecting world.

--
Ian.

[bol...@cylonhq.com]

On Tue, 15 May 2018 22:52:05 +1200

Ian Collins <ian-...@hotmail.com> wrote:
>On 15/05/18 22:17, bol...@cylonHQ.com wrote:
>> On Tue, 15 May 2018 20:41:44 +1200
>> Ian Collins <ian-...@hotmail.com> wrote:
>>> On 15/05/18 20:26, bol...@cylonHQ.com wrote:
>>>> On Mon, 14 May 2018 22:33:14 +0000 (UTC)
>>>> legaliz...@mail.xmission.com (Richard) wrote:
>>>>> [Please do not mail me a copy of your followup]
>>>>>
>>>>> bol...@cylonHQ.com spake the secret code
>>>>> <pdbhlr$1c4j$1...@gioia.aioe.org> thusly:
>>>>>
>>>>>> The posix API libraries come with every C/C++ compiler installed on every
>>>>>> unix system since god knows when. IMO that makes them standard.
>>>>>
>>>>> Spoken like a true unix bigot.
>>>>
>>>> You can also use posix on Windows, though since the windows kernel is so
>>>> limited in certain areas (process spawing & control, IPC, full signal
>>>> handling) you'll only ever be using a subset.
>>>
>>> You don't have to now we have threading as part of the standard library....
>>
>> No sane programmer uses threading if multi process can get the job done just
>> as well.
>
>Yeah right...

Well I guess if you want to have to worry about race conditions, deadlocking
and threadsafe APIs when you don't have to then go for it.

>> The only reason is so popular is because its the default parallel
>> programming mode in Windows
>
>Nope. Threads were popular before windows was inflicted on an
>unsuspecting world.

Obviously the concept had been around long before Windows, but Windows made
it popular in general programming because the sort of people who started to
code on windows had before then usually only encountered single thread programs
in DOS or on 8 bit machines with any "multitasking" being done by interrupts.
Few had used unix and even less had used mainframes (where threads started out).

[David Brown]

On 15/05/18 13:32, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 22:52:05 +1200
> Ian Collins <ian-...@hotmail.com> wrote:
>> On 15/05/18 22:17, bol...@cylonHQ.com wrote:
>>> On Tue, 15 May 2018 20:41:44 +1200
>>> Ian Collins <ian-...@hotmail.com> wrote:
>>>> On 15/05/18 20:26, bol...@cylonHQ.com wrote:
>>>>> On Mon, 14 May 2018 22:33:14 +0000 (UTC)
>>>>> legaliz...@mail.xmission.com (Richard) wrote:
>>>>>> [Please do not mail me a copy of your followup]
>>>>>>
>>>>>> bol...@cylonHQ.com spake the secret code
>>>>>> <pdbhlr$1c4j$1...@gioia.aioe.org> thusly:
>>>>>>
>>>>>>> The posix API libraries come with every C/C++ compiler installed on every
>>>>>>> unix system since god knows when. IMO that makes them standard.
>>>>>>
>>>>>> Spoken like a true unix bigot.
>>>>>
>>>>> You can also use posix on Windows, though since the windows kernel is so
>>>>> limited in certain areas (process spawing & control, IPC, full signal
>>>>> handling) you'll only ever be using a subset.
>>>>
>>>> You don't have to now we have threading as part of the standard library....
>>>
>>> No sane programmer uses threading if multi process can get the job done just
>>> as well.
>>
>> Yeah right...
>
> Well I guess if you want to have to worry about race conditions, deadlocking
> and threadsafe APIs when you don't have to then go for it.

If you think that multi-processing means you don't have to worry about
how threads of execution interact - and use locks, queues, messages,
etc., appropriately - then you are not ready to write multi-process code.

Multi-processing and multi-threading have their advantages and
disadvantages. In both cases, you need to understand what you are doing
in order to avoid subtle problems. And some tasks are best split as
threads, some tasks as processes.

>
>>> The only reason is so popular is because its the default parallel
>>> programming mode in Windows
>>
>> Nope. Threads were popular before windows was inflicted on an
>> unsuspecting world.
>
> Obviously the concept had been around long before Windows, but Windows made
> it popular in general programming because the sort of people who started to
> code on windows had before then usually only encountered single thread programs
> in DOS or on 8 bit machines with any "multitasking" being done by interrupts.
> Few had used unix and even less had used mainframes (where threads started out).
>

Threads have existed in all sorts of systems - and they are used on all
sorts of systems. The world is not restricted to *nix and Windows -
most operating systems in current use have threads but not processes.

It is certainly the case that Windows came quite late to the
multi-processing game, and even now multiple processes are much more
expensive on Windows than they would be on *nix on the same hardware.
This means that where you have a reasonable choice of strategies, it is
more common to choose a multi-threading architecture in Windows where
you might have picked a multi-processing architecture in *nix. But that
is only a bias, not an absolute divide - and *nix software is full of
threading.

[bol...@cylonhq.com]

On Tue, 15 May 2018 13:39:08 +0200
David Brown <david...@hesbynett.no> wrote:
>On 15/05/18 13:32, bol...@cylonHQ.com wrote:
>> Well I guess if you want to have to worry about race conditions, deadlocking
>> and threadsafe APIs when you don't have to then go for it.
>
>If you think that multi-processing means you don't have to worry about
>how threads of execution interact - and use locks, queues, messages,
>etc., appropriately - then you are not ready to write multi-process code.

None of the above lead to race conditions or deadlocks unless you deliberately
code them in. Which is the complete opposite of threading. Perhaps you're the
one who needs to read up a bit more on the topic though given your coding is
limited to writing data processing functions I'm not entirely surprised you're
not too up on the topic.

>Multi-processing and multi-threading have their advantages and
>disadvantages. In both cases, you need to understand what you are doing
>in order to avoid subtle problems. And some tasks are best split as
>threads, some tasks as processes.

Unfortunately some people (including the creators of java) think threads are
the answer to everything. They're a solution to a small subset of problems.

>Threads have existed in all sorts of systems - and they are used on all
>sorts of systems. The world is not restricted to *nix and Windows -
>most operating systems in current use have threads but not processes.

What is your definition of operating system since almost all embedded systems
these days either use a linux, qnx or embedded windows variant and the ones
that don't are usually running a single program with no underlying OS to speak
of, just ISRs.

>you might have picked a multi-processing architecture in *nix. But that
>is only a bias, not an absolute divide - and *nix software is full of
>threading.

It is, and a lot of it is completely unnecessary and complicates the code for
little benefit. Sometimes I've wondered if the people who wrote not only didn't
have a clue about multi process, but whether they've even heard of multiplexing.
When a program fires off a thread just to service a packet you know the coder
doesn't have much of a clue.

[David Brown]

On 15/05/18 15:23, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 13:39:08 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 15/05/18 13:32, bol...@cylonHQ.com wrote:
>>> Well I guess if you want to have to worry about race conditions, deadlocking
>>> and threadsafe APIs when you don't have to then go for it.
>>
>> If you think that multi-processing means you don't have to worry about
>> how threads of execution interact - and use locks, queues, messages,
>> etc., appropriately - then you are not ready to write multi-process code.
>
> None of the above lead to race conditions or deadlocks unless you deliberately
> code them in. Which is the complete opposite of threading.

No, it is /exactly/ the same in multi-processing and multi-threading.

A common deadlock situation is when you have two locks, A and B, and one
line of execution acquires A then B, the other tries to acquire B then
A. If each gets halfway, then the combined system deadlocks.

This is precisely the same if the locks are external file locks shared
by processes, mutexes shared by threads within a process, or any other
type of synchronisation mechanism.

There is /no/ difference.

> Perhaps you're the
> one who needs to read up a bit more on the topic though given your coding is
> limited to writing data processing functions I'm not entirely surprised you're
> not too up on the topic.

How interesting to hear - my coding is limited to writing data
processing functions, is it? Could it perhaps be that you are mixing up
posters in your eagerness to try to insult people?

>
>> Multi-processing and multi-threading have their advantages and
>> disadvantages. In both cases, you need to understand what you are doing
>> in order to avoid subtle problems. And some tasks are best split as
>> threads, some tasks as processes.
>
> Unfortunately some people (including the creators of java) think threads are
> the answer to everything. They're a solution to a small subset of problems.

Threads are not the answer to everything - but they /are/ useful, and a
good solution to many things. The same applies to multiple processes.

>
>> Threads have existed in all sorts of systems - and they are used on all
>> sorts of systems. The world is not restricted to *nix and Windows -
>> most operating systems in current use have threads but not processes.
>
> What is your definition of operating system since almost all embedded systems
> these days either use a linux, qnx or embedded windows variant and the ones
> that don't are usually running a single program with no underlying OS to speak
> of, just ISRs.

There is a saying - it is better to remain silent and be thought a fool,
than to open your mouth and prove it.

Over a certain size, Linux is dominant in complex embedded systems.
Embedded Windows variants are almost negligible in the market these days
- as is QNX, outside a few niche areas. And while most embedded systems
are "bare metal" with no OS as such, there is a very large group in the
middle with real-time operating systems like FreeRTOS, mbed, Contiki,
embOS, eCos, Integrity, MicroC/OS-II, MQX, Neutrino, DSP/BIOS, Nut/OS,
OpenRTOS, SafeRTOS, RTEMS, ThreadX, VxWorks, etc. I think without
exception these support multiple threads (with cooperative scheduling,
or pre-emptive scheduling, or both) but not multiple processes. And
though I don't have numbers - I doubt if anyone does - I expect these
far outweigh all *nix and Windows systems together, including Android.

>
>> you might have picked a multi-processing architecture in *nix. But that
>> is only a bias, not an absolute divide - and *nix software is full of
>> threading.
>
> It is, and a lot of it is completely unnecessary and complicates the code for
> little benefit. Sometimes I've wondered if the people who wrote not only didn't
> have a clue about multi process, but whether they've even heard of multiplexing.
> When a program fires off a thread just to service a packet you know the coder
> doesn't have much of a clue.
>

Firing off a thread to service a packet is a lot more efficient than
firing off a process to service it. Whether it is more or less
efficient than handling it in the current thread will depend entirely on
the application.

Prejudice against threads certainly shows that the coder does not
understand them - just as much as an obsession with always using threads.

[James Kuyper]

I'd merely have to include the functional equivalent of the HDF library
routines in my own code - which would not require anything non-standard,
but would involve a lot of platform-specific configuration, to reflect
the different representations used on different platforms for the C
standard types. The actual HDF library does use some non-standard
platform-specific facilities - but use of those facilities is optional,
they are not used when installing HDF on a platform that doesn't support
them, so it would be trivial to create a less efficient version of the
library that didn't use them at all.
Platform-specific configuration is performed by the HDF library
installation script, which is fairly complicated, because the HDF
library can be installed and work correctly on a wide variety of
platforms (but not all). My code is only required to be portable to
platforms where it can be installed.
It wouldn't be particularly difficult to copy that code, either, since
HDF is open-source. I've often had to go deep inside HDF library code to
resolve bugs, so I'm fairly familiar with it. They often were bugs in my
code causing the HDF code to fail, but on a few occasions I uncovered
bugs in the HDF code, which I reported to the HDF Group. Directly
copying their code might raise intellectual property rights issues, but
since I have no need to actually bother performing such a
transformation, I haven't bothered to look into those issues.

[bol...@cylonhq.com]

On Tue, 15 May 2018 16:09:55 +0200
David Brown <david...@hesbynett.no> wrote:

>On 15/05/18 15:23, bol...@cylonHQ.com wrote:
>> None of the above lead to race conditions or deadlocks unless you
>deliberately
>> code them in. Which is the complete opposite of threading.
>
>No, it is /exactly/ the same in multi-processing and multi-threading.
>
>A common deadlock situation is when you have two locks, A and B, and one
>line of execution acquires A then B, the other tries to acquire B then
>A. If each gets halfway, then the combined system deadlocks.

Yes, except that in multi process you almost never need explicit locking
whereas in threaded systems you almost always do. That was my point about
coding them in though apparently it whooshed right over your head.

>> Perhaps you're the
>> one who needs to read up a bit more on the topic though given your coding is
>> limited to writing data processing functions I'm not entirely surprised
>you're
>> not too up on the topic.
>
>How interesting to hear - my coding is limited to writing data
>processing functions, is it? Could it perhaps be that you are mixing up
>posters in your eagerness to try to insult people?

Well quite possibly, it seems to be interchangable whack-a-mole on here.

>> Unfortunately some people (including the creators of java) think threads are
>> the answer to everything. They're a solution to a small subset of problems.
>
>Threads are not the answer to everything - but they /are/ useful, and a
>good solution to many things. The same applies to multiple processes.

They're a good solution to some very specific things.

>> these days either use a linux, qnx or embedded windows variant and the ones
>> that don't are usually running a single program with no underlying OS to
>speak
>> of, just ISRs.
>
>There is a saying - it is better to remain silent and be thought a fool,
>than to open your mouth and prove it.

Take your own advice then.

>- as is QNX, outside a few niche areas. And while most embedded systems
>are "bare metal" with no OS as such, there is a very large group in the
>middle with real-time operating systems like FreeRTOS, mbed, Contiki,
>embOS, eCos, Integrity, MicroC/OS-II, MQX, Neutrino, DSP/BIOS, Nut/OS,
>OpenRTOS, SafeRTOS, RTEMS, ThreadX, VxWorks, etc. I think without
>exception these support multiple threads (with cooperative scheduling,
>or pre-emptive scheduling, or both) but not multiple processes. And
>though I don't have numbers - I doubt if anyone does - I expect these
>far outweigh all *nix and Windows systems together, including Android.

Well I don't have the numbers either, but I suspect its highly unlikely since
these systems would be limited to very niche areas such as aerospace whereas
embedded linux is in virtually every embedded area you can think of these
days from industrial control systems to routers to as you mentioned,
smartphones.

>> It is, and a lot of it is completely unnecessary and complicates the code for
>> little benefit. Sometimes I've wondered if the people who wrote not only
>didn't
>> have a clue about multi process, but whether they've even heard of
>multiplexing.
>> When a program fires off a thread just to service a packet you know the
>coder
>> doesn't have much of a clue.
>>
>
>Firing off a thread to service a packet is a lot more efficient than
>firing off a process to service it. Whether it is more or less
>efficient than handling it in the current thread will depend entirely on
>the application.

If the packet processing is complex and can't realistically be done in a
single thread in sufficient time using multiplexing then you'd have a thread
or process pool, you certainly wouldn't spawn a new one for each packet.

[David Brown]

On 15/05/18 16:39, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 16:09:55 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 15/05/18 15:23, bol...@cylonHQ.com wrote:
>>> None of the above lead to race conditions or deadlocks unless you
>> deliberately
>>> code them in. Which is the complete opposite of threading.
>>
>> No, it is /exactly/ the same in multi-processing and multi-threading.
>>
>> A common deadlock situation is when you have two locks, A and B, and one
>> line of execution acquires A then B, the other tries to acquire B then
>> A. If each gets halfway, then the combined system deadlocks.
>
> Yes, except that in multi process you almost never need explicit locking
> whereas in threaded systems you almost always do. That was my point about
> coding them in though apparently it whooshed right over your head.

If the processes or threads need to communicate, they need to use
methods to communicate. These are fundamentally the same for threads
and processes. You can do it with locks, mutexes, semaphores, shared
memory, message passing, file IO, pipes, and many other ways.

Any of these can give you deadlocks, livelocks, races, and other
problems if you handle them incorrectly. All of them can work fine if
you handle them correctly. The underlying principles are not different.

There is, I suppose, a tendency with threading to use lower-level
primitives that are a good deal more efficient, but might need more care
- like locks or shared memory. Similarly, there may be a tendency in
multi-processing setups to use less efficient but easier to understand
solutions like pipes. So if you don't really understand how to deal
well with communicating tasks in parallel, multi-processing and pipes
might be less error-prone than using more efficient methods.
Correctness trumps efficiency every time, of course, but the best thing
is to learn how to manage parallel tasks correctly, then choose the
architecture and communication methods based on clarity, efficiency,
scalability, flexibility, etc., rather than ignorance or prejudice.

>
>>> Perhaps you're the
>>> one who needs to read up a bit more on the topic though given your coding is
>>> limited to writing data processing functions I'm not entirely surprised
>> you're
>>> not too up on the topic.
>>
>> How interesting to hear - my coding is limited to writing data
>> processing functions, is it? Could it perhaps be that you are mixing up
>> posters in your eagerness to try to insult people?
>
> Well quite possibly, it seems to be interchangable whack-a-mole on here.

If you make wild unsubstantiated claims, your are likely to be
challenged by more than one person in a technical newsgroup. This is
your clue that you are on thin ice.

>
>>> Unfortunately some people (including the creators of java) think threads are
>>> the answer to everything. They're a solution to a small subset of problems.
>>
>> Threads are not the answer to everything - but they /are/ useful, and a
>> good solution to many things. The same applies to multiple processes.
>
> They're a good solution to some very specific things.

They are a good solution to many things, as long as you understand how
to use them. If you have a tendency to panic and worry about deadlock
when you see them, you will have trouble understanding the point of them.

>
>>> these days either use a linux, qnx or embedded windows variant and the ones
>>> that don't are usually running a single program with no underlying OS to
>> speak
>>> of, just ISRs.
>>
>> There is a saying - it is better to remain silent and be thought a fool,
>> than to open your mouth and prove it.
>
> Take your own advice then.

I have worked on small embedded systems for 25 years - I know a fair bit
about them. (That also includes an understanding of what a small part
of a big field any one developer will ever meet.) I don't know /your/
experience, but I'm guessing it is pretty low in this area.

>
>> - as is QNX, outside a few niche areas. And while most embedded systems
>> are "bare metal" with no OS as such, there is a very large group in the
>> middle with real-time operating systems like FreeRTOS, mbed, Contiki,
>> embOS, eCos, Integrity, MicroC/OS-II, MQX, Neutrino, DSP/BIOS, Nut/OS,
>> OpenRTOS, SafeRTOS, RTEMS, ThreadX, VxWorks, etc. I think without
>> exception these support multiple threads (with cooperative scheduling,
>> or pre-emptive scheduling, or both) but not multiple processes. And
>> though I don't have numbers - I doubt if anyone does - I expect these
>> far outweigh all *nix and Windows systems together, including Android.
>
> Well I don't have the numbers either, but I suspect its highly unlikely since
> these systems would be limited to very niche areas such as aerospace whereas
> embedded linux is in virtually every embedded area you can think of these
> days from industrial control systems to routers to as you mentioned,
> smartphones.

Your wild guesses don't count for much.

Just for one example, a modern car will have maybe 100-300
microcontrollers. About a quarter of these will be running an operating
system rather than bare metal code, with maybe two or three running
Linux (or, conceivably, embedded Windows) - mainly for navigation and
entertainment systems. So your car alone has more non-Linux,
non-Windows operating systems than your entire collection of computers,
smartphones, etc.

Even your smartphone will have several subsystems with their own
microcontroller running their own multi-threading OS (the cellular modem
and the Wifi module come to mind).

It is certainly true that many people would be surprised to see how many
places they have embedded Linux systems running. But non-Linux embedded
OS's outnumber them /massively/. (Bare metal systems outnumber RTOS
systems, but the difference is decreasing.)

>
>>> It is, and a lot of it is completely unnecessary and complicates the code for
>>> little benefit. Sometimes I've wondered if the people who wrote not only
>> didn't
>>> have a clue about multi process, but whether they've even heard of
>> multiplexing.
>>> When a program fires off a thread just to service a packet you know the
>> coder
>>> doesn't have much of a clue.
>>>
>>
>> Firing off a thread to service a packet is a lot more efficient than
>> firing off a process to service it. Whether it is more or less
>> efficient than handling it in the current thread will depend entirely on
>> the application.
>
> If the packet processing is complex and can't realistically be done in a
> single thread in sufficient time using multiplexing then you'd have a thread
> or process pool, you certainly wouldn't spawn a new one for each packet.
>

Thread and process pools are certainly a common solution, and are
usually more efficient than spawning new processes or threads. But
efficiency is not always the main concern in finding the best solution.
A good developer does not think one architecture is always "right", or
another architecture is always "wrong" - you look at what is the best
choice for the task in hand.

[Ian Collins]

On 15/05/18 22:17, bol...@cylonHQ.com wrote:

> On Tue, 15 May 2018 20:41:44 +1200
> Ian Collins <ian-...@hotmail.com> wrote:
>> On 15/05/18 20:26, bol...@cylonHQ.com wrote:
>>> On Mon, 14 May 2018 22:33:14 +0000 (UTC)
>>> legaliz...@mail.xmission.com (Richard) wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> bol...@cylonHQ.com spake the secret code
>>>> <pdbhlr$1c4j$1...@gioia.aioe.org> thusly:
>>>>
>>>>> The posix API libraries come with every C/C++ compiler installed on every
>>>>> unix system since god knows when. IMO that makes them standard.
>>>>
>>>> Spoken like a true unix bigot.
>>>
>>> You can also use posix on Windows, though since the windows kernel is so
>>> limited in certain areas (process spawing & control, IPC, full signal
>>> handling) you'll only ever be using a subset.
>>
>> You don't have to now we have threading as part of the standard library....
>
> No sane programmer uses threading if multi process can get the job done just
> as well.

I guess I work in an asylum then!

"as well" is a big caveat. If your threads of execution share data,
threads are the best option. If they don't and need decoupling, use
cooperating processes.

> The only reason is so popular is because its the default parallel
> programming mode in Windows which is historical baggage down to the fact that
> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
> easier to implement threading and CMT than proper pre-emptive multi tasking.

I never had cause to work with threads (or much else) on windows before
C++11. I did write plenty of threaded code on SunOS 4.

--
Ian

[Vir Campestris]

On 15/05/2018 11:17, bol...@cylonHQ.com wrote:
> No sane programmer uses threading if multi process can get the job done just
> as well. The only reason is so popular is because its the default parallel
> programming mode in Windows which is historical baggage down to the fact that
> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
> easier to implement threading and CMT than proper pre-emptive multi tasking.

Yeah, right.

That's why threads first turned up (says wikipedia) on an IBM mainframe
back in the '60s. And weren't supported by Windows until XP (if I have
it right) in about 2001. Whereas they seem to have been introduced to
Linux about 5 years earlier.

MS were in catchup mode here, you can't blame them if the design is
crap. Nor can you blame them if you can't program them correctly - which
reading your other posts is perhaps your problem.

And the only Windows that ran on that damn brain-damaged '286 (1) wasn't
even vaguely related to the Windows we have today.

Andy
--
(1) Well, it damaged my brain. I had to write a memory test for a '286
PC, which meant jumping in and out of protected mode so I could both
access the high memory and use the ROM BIOS. I had a headache every day
for a week.

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:

>On 15/05/18 22:17, bol...@cylonHQ.com wrote:

>> No sane programmer uses threading if multi process can get the job done just
>> as well.
>
>I guess I work in an asylum then!

Likewise. Threads are heavily used for our work. The problems we're
solving can't be easily decomposed into the trivially parallel operations
suitable for multiprocess solutions.

>
>"as well" is a big caveat. If your threads of execution share data,
>threads are the best option. If they don't and need decoupling, use
>cooperating processes.
>
>> The only reason is so popular is because its the default parallel
>> programming mode in Windows which is historical baggage down to the fact that
>> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
>> easier to implement threading and CMT than proper pre-emptive multi tasking.
>
>I never had cause to work with threads (or much else) on windows before
>C++11. I did write plenty of threaded code on SunOS 4.

I've been writing threaded code since 1983 (SMP mainframes,
massively parallel processor (MPP) unix systems, Unix/linux servers).

SVR4.2MP had an interesting M:N threading model (which IIRC, Solaris
also had).

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:
>On 15/05/2018 11:17, bol...@cylonHQ.com wrote:
>> No sane programmer uses threading if multi process can get the job done just
>> as well. The only reason is so popular is because its the default parallel
>> programming mode in Windows which is historical baggage down to the fact that
>> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
>> easier to implement threading and CMT than proper pre-emptive multi tasking.
>
>Yeah, right.
>
>That's why threads first turned up (says wikipedia) on an IBM mainframe
>back in the '60s. And weren't supported by Windows until XP (if I have
>it right) in about 2001. Whereas they seem to have been introduced to
>Linux about 5 years earlier.

And available in SVR4.2MP internally and shipped in 1993. Digital Unix also
had threads in the late 80's.

We had multithreaded code (SMP operating system) on the Burroughs
mainframes by 1984/5 - complete with mutex and condition variables
built into the instruction set.

http://vseries.lurndal.org/doku.php?id=instructions:lok

[Ian Collins]

On 16/05/18 10:12, Scott Lurndal wrote:
>
> SVR4.2MP had an interesting M:N threading model (which IIRC, Solaris
> also had).

It did, there was much celebration and dancing in the streets when it
was removed!

--
Ian.

[Scott Lurndal]

Well, context switches were pretty expensive back then and avoiding
them helped performance, and you could alway configure it as 1:1.

I implemented LWP support on a MPP clone of SVR4.2MP and using LWP's
directly from user mode was pretty efficient.

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<pdfh6n$o5m$3...@dont-email.me> thusly:

>That's why threads first turned up (says wikipedia) on an IBM mainframe
>back in the '60s. And weren't supported by Windows until XP (if I have
>it right) in about 2001.

Windows NT, released in 1993, had threads from the beginning.

Windows XP was the first "consumer" version of Windows that had
threads and is based on NT, just as Windows 2000 was before that. (I
consider Windows 2000 the first "consumer" version of NT, although XP
was considered by MS to be the first one that was ready for consumers
as it was compatible with more consumer software from 9x.)

[Robert Wessel]

On Tue, 15 May 2018 21:50:33 +0100, Vir Campestris
<vir.cam...@invalid.invalid> wrote:

>On 15/05/2018 11:17, bol...@cylonHQ.com wrote:
>> No sane programmer uses threading if multi process can get the job done just
>> as well. The only reason is so popular is because its the default parallel
>> programming mode in Windows which is historical baggage down to the fact that
>> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
>> easier to implement threading and CMT than proper pre-emptive multi tasking.
>
>Yeah, right.
>
>That's why threads first turned up (says wikipedia) on an IBM mainframe
>back in the '60s. And weren't supported by Windows until XP (if I have
>it right) in about 2001. Whereas they seem to have been introduced to
>Linux about 5 years earlier.
>
>MS were in catchup mode here, you can't blame them if the design is
>crap. Nor can you blame them if you can't program them correctly - which
>reading your other posts is perhaps your problem.
>
>And the only Windows that ran on that damn brain-damaged '286 (1) wasn't
>even vaguely related to the Windows we have today.

Windows NT 3.1 fully supported threads, circa 1993. It's been a core
part of the Win32 API, since day one, only the Win32s subset (unloved
and mostly unused) didn't support threads.

While some *nix had threads fairly early, there was considerable
resistance to the concept in the overall community.

[David Brown]

On 16/05/18 01:18, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
> <pdfh6n$o5m$3...@dont-email.me> thusly:
>
>> That's why threads first turned up (says wikipedia) on an IBM mainframe
>> back in the '60s. And weren't supported by Windows until XP (if I have
>> it right) in about 2001.
>
> Windows NT, released in 1993, had threads from the beginning.

That was my thought too. It was also multi-processing, but threads were
always much cheaper than processes in Windows.

I can't remember if the Win9x series supported threads - I /think/ they
did, but I am not sure. Multiple threads were not so popular in those
days as all PC's were single core - SMP was only used on big NT servers
(in the Windows world).

>
> Windows XP was the first "consumer" version of Windows that had
> threads and is based on NT, just as Windows 2000 was before that. (I
> consider Windows 2000 the first "consumer" version of NT, although XP
> was considered by MS to be the first one that was ready for consumers
> as it was compatible with more consumer software from 9x.)
>

I am not sure how they define "consumer" - perhaps "the version usually
pre-installed on computers sold to the unwashed masses". I certainly
had W2K at home - but I always installed OS's myself, rather than using
pre-installed setups. NT 4.0 was when NT became popular for
professional work, but it was not much used by consumers (who were stuck
with "Windmill" at the time).

[David Brown]

Actually, Win32s was quite well loved by those of us with Win3.x and big
programs! It was also part of the promise of running Windows programs
on OS/2, which in the days of OS/2 4.0 was way ahead of anything Windows
could provide. But when NT 4.0 came out, MS had to do something to
force OS/2 users to move to Windows - so instead of updating the support
for OS/2 to full Win32, it killed it off, including Win32s.

> While some *nix had threads fairly early, there was considerable
> resistance to the concept in the overall community.
>

I vaguely remember a war going on over at least two different types of
threading in Linux. I was not programming for Linux in those days, I
merely observed the war from a distance.

[Ian Collins]

No one was - Linux wasn't around in those days!

--
Ian

[Robert Wessel]

On Wed, 16 May 2018 08:57:23 +0200, David Brown
<david...@hesbynett.no> wrote:

>On 16/05/18 01:18, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>> <pdfh6n$o5m$3...@dont-email.me> thusly:
>>
>>> That's why threads first turned up (says wikipedia) on an IBM mainframe
>>> back in the '60s. And weren't supported by Windows until XP (if I have
>>> it right) in about 2001.
>>
>> Windows NT, released in 1993, had threads from the beginning.
>
>That was my thought too. It was also multi-processing, but threads were
>always much cheaper than processes in Windows.
>
>I can't remember if the Win9x series supported threads - I /think/ they
>did, but I am not sure. Multiple threads were not so popular in those
>days as all PC's were single core - SMP was only used on big NT servers
>(in the Windows world).

Yes, Win95, 98 and ME all supported threads, but only a single
processor (core). Only for Win32 code. Win16 code continued to run
on a single (system) thread with cooperative multitasking between the
processes. For completeness, you could have threads in the VMM,
although you were pretty far removed from normal Windows coding at
that point.

Certainly one important use of threads is exploiting multiple cores,
although that's not the only reason to use threads.

[David Brown]

LinuxThreads was from 1996, but was awkward and inefficient (it
basically made a process per thread - allowing you to compile code
designed for Posix threads, but it was not giving you the advantages of
multi-threading over multi-processing). There were two competing thread
implementations for Linux that fixed this - meaning there were three
noticeably different types of threading for a while. Eventually NPTL
won one and everyone lived happily ever after.

Coincidentally, 1996 was also the year NT 4.0 came out.

So Linux certainly /was/ around at that time, and already popular in
some environments (like HPC), but the "Linux thread wars" were a little
later.

[David Brown]

Agreed - once you get used to thread programming, they are useful for
all kinds of things. But prior to SMP (again, I'm talking about the
DOS/Windows world) PC's got faster by having faster single threaded
performance, and software generally followed that route. Event-driven
Windows programming gave you a kind of cooperative multithreading within
your program. It was only with the rise of multiple cores where
programmers /had/ to use multiple threads to improve performance that
multi-threaded programming really took off in the Windows world.

You can see a difference in the kind of networking and file I/O coding
styles that was common on Windows, compared to *nix programming. In the
Windows world, asynchronous I/O was vital to being able to do work while
waiting for data. In *nix, you would be more likely to use a thread and
blocking I/O, because it is often simpler logic in the code -
asynchronous I/O (and "select") was harder, and used when you had a lot
of things going on at once to get higher efficiency.

In small embedded systems, you generally only have a single core - but
RTOS-based systems can easily have a dozen or more threads. It is
simply a nice way to organise the program.

[bol...@cylonhq.com]

On Tue, 15 May 2018 17:39:18 +0200
David Brown <david...@hesbynett.no> wrote:

>On 15/05/18 16:39, bol...@cylonHQ.com wrote:
>and processes. You can do it with locks, mutexes, semaphores, shared
>memory, message passing, file IO, pipes, and many other ways.

Shared memory certainly has its uses, but the rest of Sys V IPC is rarely
used in my experience any more. It was always clunky and didn't play well
with the rest of the posix subsystems.

>Any of these can give you deadlocks, livelocks, races, and other
>problems if you handle them incorrectly. All of them can work fine if
>you handle them correctly. The underlying principles are not different.

Well they are, because pipes and sockets are buffered interfaces that you
can read or not read at your leisure. Not reading them has no adverse effects
upon the application wrt to blocking etc.

>- like locks or shared memory. Similarly, there may be a tendency in
>multi-processing setups to use less efficient but easier to understand
>solutions like pipes. So if you don't really understand how to deal

They're the standard method since you can multiplex on the file descriptor or
use non blocking IO or even set SIGIO. Using SysV IPC gets you into the
exact sort of race condition/locking issues that you have with threads.

>scalability, flexibility, etc., rather than ignorance or prejudice.

Given that I've been writing system and application software for unix since
the early 90s I may be prejudiced but I am certainly not ignorant on the topic.

>> Take your own advice then.
>
>I have worked on small embedded systems for 25 years - I know a fair bit
>about them. (That also includes an understanding of what a small part
>of a big field any one developer will ever meet.) I don't know /your/
>experience, but I'm guessing it is pretty low in this area.

I worked on some ticketing machines once which had multiple CPUs, all of
which ran discrete programs, not OS's.

>> these systems would be limited to very niche areas such as aerospace whereas
>> embedded linux is in virtually every embedded area you can think of these
>> days from industrial control systems to routers to as you mentioned,
>> smartphones.
>
>Your wild guesses don't count for much.

Well since there's no way of proving it one way or the other there's little
point arguing the toss about it.

>usually more efficient than spawning new processes or threads. But
>efficiency is not always the main concern in finding the best solution.

As the rapid rise of inefficient bloatware libraries that cater to people
with limited ability demonstrates.

> A good developer does not think one architecture is always "right", or
>another architecture is always "wrong" - you look at what is the best
>choice for the task in hand.

Can't disagree there.

[bol...@cylonhq.com]

On Tue, 15 May 2018 21:50:33 +0100
Vir Campestris <vir.cam...@invalid.invalid> wrote:
>On 15/05/2018 11:17, bol...@cylonHQ.com wrote:
>> No sane programmer uses threading if multi process can get the job done just
>> as well. The only reason is so popular is because its the default parallel
>> programming mode in Windows which is historical baggage down to the fact that
>> Windows had to run with the primitive MMUs on the 8086 and 286 and it was
>> easier to implement threading and CMT than proper pre-emptive multi tasking.
>
>Yeah, right.
>
>That's why threads first turned up (says wikipedia) on an IBM mainframe
>back in the '60s. And weren't supported by Windows until XP (if I have

Really? How do you think all the various GUI events were run in the background
then while your application ran its main thread? Or do you remember having
to - for example - explicitely program the cursor to flash in a text box?

[bol...@cylonhq.com]

On Wed, 16 May 2018 08:57:23 +0200
David Brown <david...@hesbynett.no> wrote:
>On 16/05/18 01:18, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>> <pdfh6n$o5m$3...@dont-email.me> thusly:
>>
>>> That's why threads first turned up (says wikipedia) on an IBM mainframe
>>> back in the '60s. And weren't supported by Windows until XP (if I have
>>> it right) in about 2001.
>>
>> Windows NT, released in 1993, had threads from the beginning.
>
>That was my thought too. It was also multi-processing, but threads were
>always much cheaper than processes in Windows.

Since windows couldn't (and AFAIK still doesn't) support fork(), spawning
a child process in windows to accomplish a subtask is pretty futile as
it had to start from main() again with presumably a load of command line
parameters required to tell it what to do. God knows how you'd pass any
binary data in, I guess a temporary file. Ugh.

[bol...@cylonhq.com]

On Wed, 16 May 2018 09:01:18 +0200
David Brown <david...@hesbynett.no> wrote:
>I vaguely remember a war going on over at least two different types of
>threading in Linux. I was not programming for Linux in those days, I
>merely observed the war from a distance.

Up until kernel 2.2 or 2.4, I forget which, threads were actually seperate
processes in disguise with a wrapper library hiding all the nasty implementation
details.

[Robert Wessel]

No the debate I was referring to preceded that. This was before
widespread implementation of threads in Unix, and mostly (completely?)
before Linux. IIRC, from the mid eighties to the early nineties, give
or take. A large portion of the Unix community took the position that
"threads are evil, processes are all you need". Suggesting that Unix
*should* have threads often provoked a rude response.

There were certainly exceptions, mainly from *nix vendors who made big
(MP) machines.

[David Brown]

Correct - Windows does not support fork(). You can do spawn, which
(IIUIC) is like fork then exec, and you can, I think, do a vfork().
This is one of the key points where multi-processing on Windows is
significantly less efficient than on Linux (or other *nix), and of the
main reasons you don't use a "fork off lots of child processes to handle
connections" model for server code in Windows as you often do in *nix.

Of course it is still entirely possible to use multiple processes on
Windows - you just have to work a little harder to hide the messy
details. If you use Python, for example, you can do your parallel
coding using the "threading" module or the "multiprocessing" module,
with almost identical interfaces for each, and work in the same simple
way on Linux or Windows. You pay a performance penalty for the
abstraction, especially if you use a model that does not fit well with
the OS, but it all works with minimal programmer effort.

[David Brown]

Ah, well, that was before my time. I didn't start programming until
about 1980, and as an eight-year-old I didn't have much access to Unix
systems :-(

[bol...@cylonhq.com]

On Wed, 16 May 2018 11:23:21 +0200
David Brown <david...@hesbynett.no> wrote:
>Ah, well, that was before my time. I didn't start programming until
>about 1980, and as an eight-year-old I didn't have much access to Unix
>systems :-(

My school in the 70s had a timesharing system called Equinox something or
other. God knows what OS it ran but it allowed us to program Basic on the
terminals. Had a habit of crashing quite often IIRC so the teacher used to
sit next to the machine ready to press the reset button.

[Ian Collins]

Indeed! Some of the first C++ I wrote (early 90s) was a "thread"
wrapper library around SunOS LWPs. It provided a better platform for
modeling our embedded RTOS than earlier attempts using processes. That
was probably where I got the thread bug.

--
Ian.

[Paavo Helde]

On 16.05.2018 11:47, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 17:39:18 +0200
> David Brown <david...@hesbynett.no> wrote:
>
> Shared memory certainly has its uses, but the rest of Sys V IPC is rarely
> used in my experience any more. It was always clunky and didn't play well
> with the rest of the posix subsystems.
>
>> Any of these can give you deadlocks, livelocks, races, and other
>> problems if you handle them incorrectly. All of them can work fine if
>> you handle them correctly. The underlying principles are not different.
>
> Well they are, because pipes and sockets are buffered interfaces that you
> can read or not read at your leisure. Not reading them has no adverse effects
> upon the application wrt to blocking etc.

Buffered interfaces are great for distributing and synchronizing work,
that's the reason whay they are used extensively in multi-threaded
programming. In C++ they are often called message queues and can be
implemented easily by using for example a std::deque, a std::mutex and a
std::condition_variable.

For example, the Windows windowing infrastructure is built upon such
multithread-enabled queues (window event queues).

>> - like locks or shared memory. Similarly, there may be a tendency in
>> multi-processing setups to use less efficient but easier to understand
>> solutions like pipes. So if you don't really understand how to deal
>
> They're the standard method since you can multiplex on the file descriptor or

Multiplexing on a file descriptor is similar to a wait on a
std::condition_variable. A drawback is that it's less portable since in
Windows select() et al only work on limited types of resource descriptors.

> use non blocking IO or even set SIGIO.

Using non-blocking IO means polling which is either a resource hog or
causes slower response times. So it is suited only for some special
situations.

Signals are also not so portable and they are tricky to use in C++
anyway. The most sane way to deal with signals in C++ (sigwait())
basically assumes creating a new thread in the first place and
translating the signals to inter-thread events. It's also non-portable
of course.

Also, most C++ code goes into libraries which are expected to work in
arbitrary client applications and cannot just hijack the process-wide
signal mechanisms.

[David Brown]

On 16/05/18 10:47, bol...@cylonHQ.com wrote:
> On Tue, 15 May 2018 17:39:18 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 15/05/18 16:39, bol...@cylonHQ.com wrote:
>> and processes. You can do it with locks, mutexes, semaphores, shared
>> memory, message passing, file IO, pipes, and many other ways.
>
> Shared memory certainly has its uses, but the rest of Sys V IPC is rarely
> used in my experience any more. It was always clunky and didn't play well
> with the rest of the posix subsystems.
>
>> Any of these can give you deadlocks, livelocks, races, and other
>> problems if you handle them incorrectly. All of them can work fine if
>> you handle them correctly. The underlying principles are not different.
>
> Well they are, because pipes and sockets are buffered interfaces that you
> can read or not read at your leisure. Not reading them has no adverse effects
> upon the application wrt to blocking etc.

Of course it does.

It is certainly conceptually easier to work with queues of various sorts
when synchronising data between parallel code streams. One of the
important uses of locks and mutexes is to implement queues, fifos,
message buffers, etc.

But it is easy to deadlock processes using queues - if process P1 waits
for data coming in on Q1 before sending out on Q2, and process P2 waits
for data coming in on Q2 before sending out on Q1. Queues (pipes,
sockets, whatever) can be used to simulate locks and mutexes, and
therefore can be used to get the same deadlocking. Pretty much /any/
synchronisation method can be used to implement any other one - they are
therefore equivalent in terms of the things you can do with them,
including the mistakes you can make. But they differ significantly in
terms of efficiency for various tasks, convenience, and the ease of
getting particular tasks right, and the difficulty of getting particular
tasks wrong.

So you /can/ deadlock with pipes - you are just a good deal less likely
to do it accidentally. This is also why message passing and queues are
often a good way to handle inter-thread communication, not just
inter-process communication.

>
>> - like locks or shared memory. Similarly, there may be a tendency in
>> multi-processing setups to use less efficient but easier to understand
>> solutions like pipes. So if you don't really understand how to deal
>
> They're the standard method since you can multiplex on the file descriptor or
> use non blocking IO or even set SIGIO. Using SysV IPC gets you into the
> exact sort of race condition/locking issues that you have with threads.
>
>> scalability, flexibility, etc., rather than ignorance or prejudice.
>
> Given that I've been writing system and application software for unix since
> the early 90s I may be prejudiced but I am certainly not ignorant on the topic.

Your high prejudice against threads suggests you are ignorant, or at
least inexperienced, in using them. Of course there is sense in using
what you know - if a particular architecture works for you and your
needs, then there may not be any point in looking at other solutions.
Just don't make the mistake of thinking that your way is the /only/ way,
or that everyone else is wrong.

>
>>> Take your own advice then.
>>
>> I have worked on small embedded systems for 25 years - I know a fair bit
>> about them. (That also includes an understanding of what a small part
>> of a big field any one developer will ever meet.) I don't know /your/
>> experience, but I'm guessing it is pretty low in this area.
>
> I worked on some ticketing machines once which had multiple CPUs, all of
> which ran discrete programs, not OS's.

You make that sound like something from long ago. Small RTOS's were
less used in older times - they need a bit more processing power and
memory than you used to get with 8051 and similar devices. But as you
can get ARM core microcontrollers for $0.30, developers have the freedom
to use them for flexibility.

>
>>> these systems would be limited to very niche areas such as aerospace whereas
>>> embedded linux is in virtually every embedded area you can think of these
>>> days from industrial control systems to routers to as you mentioned,
>>> smartphones.
>>
>> Your wild guesses don't count for much.
>
> Well since there's no way of proving it one way or the other there's little
> point arguing the toss about it.
>

I invite you to google a bit. You probably won't get accurate numbers
(I couldn't find any), but you will see enough to get an idea of the trends.

>> usually more efficient than spawning new processes or threads. But
>> efficiency is not always the main concern in finding the best solution.
>
> As the rapid rise of inefficient bloatware libraries that cater to people
> with limited ability demonstrates.

Tell me, do you take your car when you go to the shops? Isn't it a bit
inefficient to move a couple of tons of metal when all you really want
to do is move a few pints of milk and a loaf of bread? You do it
because it is far more convenient to the user. When you want to move 20
tons of milk to deliver to the shop, on the other hand, you use a
different ratio for better efficiency.

It's the same in development. Sometimes the emphasis should be on
developer time, sometimes it should be on processor run time. Usually,
it is somewhere in between.

>
>> A good developer does not think one architecture is always "right", or
>> another architecture is always "wrong" - you look at what is the best
>> choice for the task in hand.
>
> Can't disagree there.
>

Ah, agreement at last!

[Scott Lurndal]

bol...@cylonHQ.com writes:
>On Tue, 15 May 2018 17:39:18 +0200
>David Brown <david...@hesbynett.no> wrote:
>>On 15/05/18 16:39, bol...@cylonHQ.com wrote:
>>and processes. You can do it with locks, mutexes, semaphores, shared
>>memory, message passing, file IO, pipes, and many other ways.
>
>Shared memory certainly has its uses, but the rest of Sys V IPC is rarely
>used in my experience any more. It was always clunky and didn't play well
>with the rest of the posix subsystems.

Consider the history. shmat/semops were introduced from a branch
of unix within AT&T (PWB/Unix, IIRC).

However, there are now posix versions of both that fit better into
the unix namespace philosophy.

>
>>Any of these can give you deadlocks, livelocks, races, and other
>>problems if you handle them incorrectly. All of them can work fine if
>>you handle them correctly. The underlying principles are not different.
>
>Well they are, because pipes and sockets are buffered interfaces that you
>can read or not read at your leisure. Not reading them has no adverse effects
>upon the application wrt to blocking etc.

Writes to pipes and fifos may block if the reader doesn't read.

[Scott Lurndal]

Paavo Helde <myfir...@osa.pri.ee> writes:
>On 16.05.2018 11:47, bol...@cylonHQ.com wrote:

>> use non blocking IO or even set SIGIO.
>
>Using non-blocking IO means polling which is either a resource hog or
>causes slower response times. So it is suited only for some special
>situations.

One can also use lio_listio, aio_read, aio_write, et alia. I used
lio_listio extensively (with list sizes exceeding 100 buffers at times)
in a port of Oracle to an MPP machine.

[David Brown]

The first time one of my schools got a computer, I was in charge of it -
aged 12. I knew far more about it than any of the teachers.

[Scott Lurndal]

Digital Unix and SVR4/MP both had threading models
in the early 80's/90's. About the same time, POSIX 1003.4
was being developed (called realtime extensions, which included pthreads).

> A large portion of the Unix community took the position that
>"threads are evil, processes are all you need".

I was there, deep in the standards process in the early
90's and what you say does not ring true. There may have
been such voices, but they did not encompass a "large portion of the
unix community".

>Suggesting that Unix
>*should* have threads often provoked a rude response.
>
>There were certainly exceptions, mainly from *nix vendors who made big
>(MP) machines.

Well, that was me :-).

[Scott Lurndal]

1974 for me (at thirteen) Basic on a B5500, first assembler on PDP-8 in
1976, first high-level systems language (SPL) on an HP-3000 in
1977 and first C on UnixV6 in 1979.

[bol...@cylonhq.com]

On Wed, 16 May 2018 15:56:14 +0200
David Brown <david...@hesbynett.no> wrote:
>On 16/05/18 10:47, bol...@cylonHQ.com wrote:
>> Well they are, because pipes and sockets are buffered interfaces that you
>> can read or not read at your leisure. Not reading them has no adverse effects
>> upon the application wrt to blocking etc.
>
>Of course it does.
>
>It is certainly conceptually easier to work with queues of various sorts
>when synchronising data between parallel code streams. One of the
>important uses of locks and mutexes is to implement queues, fifos,
>message buffers, etc.
>
>But it is easy to deadlock processes using queues - if process P1 waits
>for data coming in on Q1 before sending out on Q2, and process P2 waits
>for data coming in on Q2 before sending out on Q1. Queues (pipes,

Except you'd (almost) never have a process sitting in a read() waiting for
input or stuck in a write() waiting to output, the pipe or socket descriptor
would be multiplexed in select() or poll().

>> Given that I've been writing system and application software for unix since
>> the early 90s I may be prejudiced but I am certainly not ignorant on the
>topic.
>
>Your high prejudice against threads suggests you are ignorant, or at

No, I spent enough time bug fixing huge threaded applications with endless
race conditions that were often unrepeatable and the occasional deadlock to
come to the conclusion that threads are more trouble that they're worth unless
each thread generally keeps to itself and/or doesn't make many calls that could
cause issues.

>> which ran discrete programs, not OS's.
>
>You make that sound like something from long ago. Small RTOS's were

Mid 90s.

>> As the rapid rise of inefficient bloatware libraries that cater to people
>> with limited ability demonstrates.
>
>Tell me, do you take your car when you go to the shops? Isn't it a bit

No. I live 300m away from them.

>It's the same in development. Sometimes the emphasis should be on
>developer time, sometimes it should be on processor run time. Usually,
>it is somewhere in between.

True, but the trend seems to be increasingly on speed of development, agile
etc, rather than efficiency and quality of code. The pendulum has swung way
to far in favour of lego brick coding which is why we have multi core CPUs on
multi CPU machines being brought to their knees running applications that
could happily run on the hardware of 20 years ago.

[bol...@cylonhq.com]

On Wed, 16 May 2018 13:57:09 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>bol...@cylonHQ.com writes:
>>On Tue, 15 May 2018 17:39:18 +0200
>>David Brown <david...@hesbynett.no> wrote:
>>>On 15/05/18 16:39, bol...@cylonHQ.com wrote:
>>>and processes. You can do it with locks, mutexes, semaphores, shared
>>>memory, message passing, file IO, pipes, and many other ways.
>>
>>Shared memory certainly has its uses, but the rest of Sys V IPC is rarely
>>used in my experience any more. It was always clunky and didn't play well
>>with the rest of the posix subsystems.
>
>Consider the history. shmat/semops were introduced from a branch
>of unix within AT&T (PWB/Unix, IIRC).
>
>However, there are now posix versions of both that fit better into
>the unix namespace philosophy.

To be fair I'd forgotten about them. Yes, they're more powerful with a saner
interface but the message queues require a non default filesystem mount in
linux.

>>Well they are, because pipes and sockets are buffered interfaces that you
>>can read or not read at your leisure. Not reading them has no adverse effects
>>upon the application wrt to blocking etc.
>
>Writes to pipes and fifos may block if the reader doesn't read.

Thats why the select() function has a write mask for you to check if its
writable first. Its probably not infallable but since most pipe interactions
will be synchronous its highly unlikely one program will fill up the pipe
buffer unless the reader has hung and in that case it won't matter anyway.

[Paavo Helde]

On 16.05.2018 18:03, bol...@cylonHQ.com wrote:
> On Wed, 16 May 2018 15:56:14 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 16/05/18 10:47, bol...@cylonHQ.com wrote:
>>> Well they are, because pipes and sockets are buffered interfaces that you
>>> can read or not read at your leisure. Not reading them has no adverse effects
>>> upon the application wrt to blocking etc.
>>
>> Of course it does.
>>
>> It is certainly conceptually easier to work with queues of various sorts
>> when synchronising data between parallel code streams. One of the
>> important uses of locks and mutexes is to implement queues, fifos,
>> message buffers, etc.
>>
>> But it is easy to deadlock processes using queues - if process P1 waits
>> for data coming in on Q1 before sending out on Q2, and process P2 waits
>> for data coming in on Q2 before sending out on Q1. Queues (pipes,
>
> Except you'd (almost) never have a process sitting in a read() waiting for
> input or stuck in a write() waiting to output, the pipe or socket descriptor
> would be multiplexed in select() or poll().

So the process would sit in select() indefinitely. This would be the
same deadlock. But to be fair, I personally have not seen a deadlock
with queues, either in-process mutex-protected ones or inter-process
pipes. Probably this is because with queues one typically has pretty
well-defined producers and consumers which helps to avoid circular
dependencies.

Deadlocks appear if threads or processes lock multiple data structures
at the same time in a different order. For different processes this
means to lock *external* data structures, like flock() on files. Threads
in the same process can lock also internal data structures in memory and
as this is easier and done with less thought there are more chances to
get it wrong. So I kind of agree with you that multi-process approach
would be less prone to deadlocks in general (at the expense of
duplicating all mutable data structures and needing more tedious ways to
keep them synchronized).

>
>>> Given that I've been writing system and application software for unix since
>>> the early 90s I may be prejudiced but I am certainly not ignorant on the
>> topic.
>>
>> Your high prejudice against threads suggests you are ignorant, or at
>
> No, I spent enough time bug fixing huge threaded applications with endless
> race conditions that were often unrepeatable and the occasional deadlock to
> come to the conclusion that threads are more trouble that they're worth unless
> each thread generally keeps to itself and/or doesn't make many calls that could
> cause issues.

C++ is certainly a language where one can mess up in horrific ways and
lots of things which can be done should be not done. That's nothing new,
except that multithreading bugs are often harder to catch and fix.

>
>>> which ran discrete programs, not OS's.
>>
>> You make that sound like something from long ago. Small RTOS's were
>
> Mid 90s.
>
>>> As the rapid rise of inefficient bloatware libraries that cater to people
>>> with limited ability demonstrates.
>>
>> Tell me, do you take your car when you go to the shops? Isn't it a bit
>
> No. I live 300m away from them.
>
>> It's the same in development. Sometimes the emphasis should be on
>> developer time, sometimes it should be on processor run time. Usually,
>> it is somewhere in between.
>
> True, but the trend seems to be increasingly on speed of development, agile
> etc, rather than efficiency and quality of code. The pendulum has swung way
> to far in favour of lego brick coding which is why we have multi core CPUs on
> multi CPU machines being brought to their knees running applications that
> could happily run on the hardware of 20 years ago.

The hardware today costs less then the hardware of 20 years ago, so this
is pretty much expected. The software expands to fill all the available
memory and cores, that's just economics. And to fill all the cores the
current solution is to be multi-threaded. Lots of C++ code is in
libraries running in arbitrary processes, and it would not be safe to
fork the process without immediate exec anyway, as soon as the original
process might ever have more than one threads.

So, multithreading is the current way to go, like it or not. To keep it
manageable it is indeed a good idea to have very independent threads and
only use message queues for communicating with them. This basically
reproduces the multi-process pipe solution in a single process, a bit
more efficiently and a bit more prone to errors.

[bol...@cylonhq.com]

On Wed, 16 May 2018 21:07:28 +0300
Paavo Helde <myfir...@osa.pri.ee> wrote:
>On 16.05.2018 18:03, bol...@cylonHQ.com wrote:
>> Except you'd (almost) never have a process sitting in a read() waiting for
>> input or stuck in a write() waiting to output, the pipe or socket descriptor
>> would be multiplexed in select() or poll().
>
>So the process would sit in select() indefinitely. This would be the

Not really, you just wait for something to happen. You may have multiplexed
50 file descriptors and if one is blocking then you can service the others.
Plus select() has a timeout so the program can go do something else if
there's nothing coming down the pipes or sockets.

>would be less prone to deadlocks in general (at the expense of
>duplicating all mutable data structures and needing more tedious ways to
>keep them synchronized).

Yes, there is more work with multiprocess with data sharing. Obviously if
you need to split up huge amounts of data to pass through some processing
then join it all back together you're better off with threads.

>> No, I spent enough time bug fixing huge threaded applications with endless
>> race conditions that were often unrepeatable and the occasional deadlock to
>> come to the conclusion that threads are more trouble that they're worth
>unless
>> each thread generally keeps to itself and/or doesn't make many calls that
>could
>> cause issues.
>
>C++ is certainly a language where one can mess up in horrific ways and
>lots of things which can be done should be not done. That's nothing new,
>except that multithreading bugs are often harder to catch and fix.

Not just C++, I've seen pthread nightmares in plain C too.

>is pretty much expected. The software expands to fill all the available
>memory and cores, that's just economics. And to fill all the cores the

No, thats just lazy programming. The amount of extra functionality brought
by faster CPUs has no way increased with the amount of extra horsepower and
memory required by applications. I'll make an exception for things like
video editing and other maths intensive systems, but when you look at a dog
like MS Word and what it can do compared to what it could do 20 years ago
then look at the minimum spec required to run it now, its just farcical.

[Christian Gollwitzer]

Am 16.05.18 um 10:50 schrieb bol...@cylonHQ.com:

It worked by cooperative multitasking. Even today, GUI libraries do not
use threads to make the widgets run seemingly in parallel. All that I
know of use event loops for that, i.e. in the core it is a big select()
loop (with timeouts to handle regular tasks like updating the display of
a clock).

Windows 3.11 supported preemptive multitasking (IIRC it was a
configurable option even), before that ALL programs shared a single big
event loop, with the consequences that a single stalled program would
halt the whole machine, including the blinking cursor.

Christian

[red floyd]

Anything that supported the Win32 API -- 95, 98, Me, all flavors of NT,
XP, Vista, 7, 8, and 10 -- had threading. It may not have been the
world's best implementation (9x and Me), but they supported threads.

[Robert Wessel]

Win32s did not.

[Robert Wessel]

At least for Windows applications, using the normal APIs, none of the
Win3.x family supported preemptive multitasking. You *could* do some
things like that in the VxD layer, or between multiple DOS sessions
(at least if you were running in 386Enh mode).

The fixes in later versions of Win16 for the single input queue did
not create preemptive multitasking, tasks could still only switch when
a Yield() was executed (which usually happened under the hood during
message processing), but under certain circumstances input messages
were considered processed as soon as the task accepted them, rather
than when the task returned for another message.

[David Brown]

Yes, it was weird like that - you could have pre-emptive multitasking of
DOS sessions, but not Windows programs on Win3.x. (OS/2 was far better
for running Windows and DOS programs at the time, as it /did/ support
pre-emptive multitasking. It still suffered from a single input queue
until 4.0 - that was MS' contribution to the joint OS/2 project.)

> The fixes in later versions of Win16 for the single input queue did
> not create preemptive multitasking, tasks could still only switch when
> a Yield() was executed (which usually happened under the hood during
> message processing), but under certain circumstances input messages
> were considered processed as soon as the task accepted them, rather
> than when the task returned for another message.
>

I believe MacOS continued with cooperative multitasking for a long time
after Windows had switched to pre-emptive. But it worked on the Mac,
mainly because Mac application developers understood that cooperative
multitasking meant playing nice with other programs. Windows developers
often had a DOS background, and were used to the idea of being in full
control of the machine - yield() was not commonly used.