Saturday, January 25, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

Bart <bc@freeuk.com>: Jan 25 01:19AM

On 24/01/2020 23:05, David Brown wrote:
> simplest, clearest, and most maintainable option.  The reason I don't
> use goto's myself is that I have never found it to be the best choice
> for my code - not because of a particular allergy against it.
 
Well, I've never seen any actual code of yours, only fragments that you
might post, so I don't know what the cost might be in terms of
readability, or loss of localisation (eg. when you have to invent dummy
functions etc to avoid use of goto) or things like that. (Or how much
longer it takes to write such code.)
 
I can only repeat that the Linux kernel seems to use a lot, about
163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
 
That's a frequency of once every 152 or 117 lines.
 
Even within only the header files, there are 500 gotos in some 6M lines
of headers, or once every 12,000 lines; still far more that you write in
actual C code.
 
Or C++; as I said earlier, it's not clear how much C++ helps avoiding
gotos compared with C. C++-style exceptions would be handled by longjmp
in C? Then that wouldn't count as a goto.
 
On the subject of never using a common feature of a language (or
development system), then I've never written a makefile. And in the last
1.7Kloc pure C module I wrote, I didn't use a single macro.
 
I tend to use gotos to share the same fragment of code within a
function. I once came up with a new feature to make that possible
without gotos, like in-place, lightweight, not-parameterised local
functions, but their use resembled Basic's GOSUB; I decided I might as
well just use goto!
"Öö Tiib" <ootiib@hot.ee>: Jan 24 05:34PM -0800

On Friday, 24 January 2020 11:36:39 UTC+2, Paavo Helde wrote:
 
> FWIW, I just grepped our C++ codebase (600 KLOC) for goto, it appears
> there is one goto per 8000 lines. This is a bit surprising, I did not
> expect so many gotos.
 
Often it just is not worth to refactor code to get rid of gotos.
Real programmer can write fortran-program in any programming
language and gotos are smallest of issues with such.
Siri Cruise <chine.bleu@yahoo.com>: Jan 24 05:57PM -0800

In article
<acfc347c-239e-4916-9ce8-8489d173018e@googlegroups.com>,
 
> Often it just is not worth to refactor code to get rid of gotos.
> Real programmer can write fortran-program in any programming
> language and gotos are smallest of issues with such.
 
gotos are usually the easy and efficient way to write FSMs.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 24 11:21PM -0500

On 1/24/20 3:27 PM, Paavo Helde wrote:
...
> How come? How one can sanely cope with error checking in C without goto,
> if there is even a single resource to be released before error return?
 
You might consider my approach insane. Instead of using goto to make
sure the resource is released, I release each resource at the end of the
block that is entered if and only if that resource was successfully
allocated, and I make sure never to leave that block by any means other
than passing through the release statement. And I only use C's other
flow control statements, not "goto", to make that happen. And that is
true separately for each such resource.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 24 11:24PM -0500

On 1/24/20 5:12 PM, Jorgen Grahn wrote:
> On Fri, 2020-01-24, Bart wrote:
...
>> I can't see much in C++ that would eliminate the use-cases for goto in C.
 
> Of course not -- how could a feature in language X eliminate the need
> for another feature in language Y?
 
I suspect he meant "I can't see much in C++ that would eliminate, in
C++, the use-cases that, in C, justify the use of goto."
 
The only reasonably plausible justifications I've seen for using "goto"
are for error handling, and the kind of error handling that justifies
using "goto" is handled somewhat more easily in C++ by using exceptions,
but I'm not at all surprised if Bart can't see that.
Ian Collins <ian-news@hotmail.com>: Jan 25 07:50PM +1300

On 25/01/2020 14:19, Bart wrote:
 
> I can only repeat that the Linux kernel seems to use a lot, about
> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
 
> That's a frequency of once every 152 or 117 lines.
 
That's also C.
 
> Or C++; as I said earlier, it's not clear how much C++ helps avoiding
> gotos compared with C. C++-style exceptions would be handled by longjmp
> in C? Then that wouldn't count as a goto.
 
RAII takes care of one of the most common use of goto in C which is
freeing allocated resources on error. It also allows early returns
which eliminates another significant use of goto in C.
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 09:04AM

On Sat, 2020-01-25, James Kuyper wrote:
>> for another feature in language Y?
 
> I suspect he meant "I can't see much in C++ that would eliminate, in
> C++, the use-cases that, in C, justify the use of goto."
 
Seems right, based on his later posting: "as I said earlier, it's not
clear how much C++ helps avoiding gotos compared with C".
 
I had a hard time understanding what this subthread was all about,
so I didn't want to take a guess on what he meant.
 
> The only reasonably plausible justifications I've seen for using "goto"
> are for error handling, and the kind of error handling that justifies
> using "goto" is handled somewhat more easily in C++ by using exceptions,
 
That too, but mostly by RAII, as Ian pointed out.
 
> but I'm not at all surprised if Bart can't see that.
 
I'm mildly surprised that he cares.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bart <bc@freeuk.com>: Jan 25 11:57AM

On 25/01/2020 06:50, Ian Collins wrote:
>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
 
>> That's a frequency of once every 152 or 117 lines.
 
> That's also C.
 
David Brown said:
 
"I can only ever remember /once/ using "goto" in C code..."
"Öö Tiib" <ootiib@hot.ee>: Jan 25 04:15AM -0800

On Saturday, 25 January 2020 06:25:04 UTC+2, James Kuyper wrote:
> are for error handling, and the kind of error handling that justifies
> using "goto" is handled somewhat more easily in C++ by using exceptions,
> but I'm not at all surprised if Bart can't see that.
 
It is actually possible on lot of cases with gotos to optimize out
duplicate condition checks, switch cases, calls through (possibly
member) function pointers or virtual function calls. It indeed
often also means that the result is slightly harder to follow,
to extend and to test.
 
Any such micro-performance optimizations should be avoided unless
profiler shows that there is something to gain. Profiler however
typically shows that less than 5% of code base contributes
anything to time consumption.
 
However when the goto is already written, the tests are already
present and there are no reasons to expect that it needs to be
extended soon then I do not understand why to refactor it?
It feels to be waste of effort. Why to risk breaking working
code? Why to gain reduced efficiency? The gotos are very
local (unlike for example macros or exceptions) so the impact
is minimal.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 25 01:42PM

On Sat, 25 Jan 2020 11:57:24 +0000
 
> > That's also C.
 
> David Brown said:
 
> "I can only ever remember /once/ using "goto" in C code..."
 
And you said:
 
"Or C++; as I said earlier, it's not clear how much C++ helps avoiding
gotos compared with C. C++-style exceptions would be handled by longjmp
in C? Then that wouldn't count as a goto."
 
The point you were missing, and still seem to be missing, is that C++'s
RAII (which caters for early returns) dispenses with the need to use
goto's and labels for implementing what amounts to finally clauses in C,
which is probably its most common usage in the linux kernel.
Bart <bc@freeuk.com>: Jan 25 02:58PM

On 25/01/2020 13:42, Chris Vine wrote:
> RAII (which caters for early returns) dispenses with the need to use
> goto's and labels for implementing what amounts to finally clauses in C,
> which is probably its most common usage in the linux kernel.
 
I chose one random file, workqueue.c, and scanned a few gotos. They
seemed to be backward jumps. For example:
 
reflush:
flush_workqueue(wq);
 
mutex_lock(&wq->mutex);
 
for_each_pwq(pwq, wq) {
bool drained;
 
spin_lock_irq(&pwq->pool->lock);
drained = !pwq->nr_active && list_empty(&pwq->delayed_works);
spin_unlock_irq(&pwq->pool->lock);
 
if (drained)
continue;
 
if (++flush_cnt == 10 ||
(flush_cnt % 100 == 0 && flush_cnt <= 1000))
pr_warn("workqueue %s: drain_workqueue() isn't complete after %u
tries\n",
wq->name, flush_cnt);
 
mutex_unlock(&wq->mutex);
goto reflush;
}
 
This looks like it really needs two nested loops rather than one, but
probably requires nested loop controls, so means extra flags.
 
How would C++ help here, to avoid either that extra logic, or the use of
that goto? Here's the current outline (for_each_pwq is a macro expanding
to a regular for-header):
 
L:
A;
for (...) {
B;
if (C) continue;
D;
goto L;
}
 
This can be done without gotos and without additional logic in my own
language, as it supports nested loop controls:
 
do
A
for ... do
B
if C then next fi # next=continue, sort of
D
redo all # restart outer loop body
 
end
exit # exit=break
end
 
(Another way is for the outer loop to be 'to 1 do', execute once, to
avoid that exit.)
 
So I genuinely have features to help cut back on use of goto, yet I
still use goto because, as I said, I mainly use it for share code
fragments within a function.
 
(I then looked at one more example, which was this (umh.c), here only
outlined:
 
...
if (A) {
B;
if (C) {
D;
goto L;
}
}
 
E;
L:
G;
} // end of function
 
Any ideas? This one seems more about code-sharing. I'm still interested
in any C++ magic to help out. Rewriting 25MLoC is not a helpful
suggestion...)
Ian Collins <ian-news@hotmail.com>: Jan 26 07:45AM +1300

On 26/01/2020 00:57, Bart wrote:
 
>> That's also C.
 
> David Brown said:
 
> "I can only ever remember /once/ using "goto" in C code..."
 
You asked the question, which you have snipped: "Or C++; as I said
earlier, it's not clear how much C++ helps avoiding gotos compared with C."
 
What do you have to say about my answer?
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Jan 25 07:55PM +0100

On 25/01/2020 05:24, James Kuyper wrote:
> are for error handling, and the kind of error handling that justifies
> using "goto" is handled somewhat more easily in C++ by using exceptions,
> but I'm not at all surprised if Bart can't see that.
 
"goto" is not used in C for error handling as such - it is used to
handle deallocation of resources in the face of abnormal program flow
(such as in the case of an error, but possibly from other situations).
And the way this is handled in C++ is not exceptions - it is RAII.
Exceptions are used to be able to pass control to a separate block with
little source code needed in between - thus letting you have error
handling without having to write the error handling manually in the code
that could have an error.
 
 
So in C, people (not everyone, but some people write) :
 
Get resource 1
if (failed) goto exit
if (leave early) goto release1
Get resource 2
if (failed) goto release1
if (leave early) goto release2
 
Use resource 1 and resource 2
 
release2:
Release resource 2
release1:
Release resource 1
exit:
return
 
 
In C++, you can write:
 
auto r1 = Get resource 1
if (failed or leave early) return
auto r2 = Get resource 2
if (failed or leave early) return
Use resource 1 and resource 2
return
 
You can use early return, break, exceptions, goto, or whatever you want
to leave the code block. It is the /RAII/ that avoids the "goto" and
labels collections needed to handle leak-free early exit, not exceptions.
Ian Collins <ian-news@hotmail.com>: Jan 26 07:58AM +1300

On 26/01/2020 03:58, Bart wrote:
> }
 
> This looks like it really needs two nested loops rather than one, but
> probably requires nested loop controls, so means extra flags.
 
As you say, just using two loops, possibly extracting the logic in the
last if the to a function to use as the loop control, would be an
appropriate fix. This is just a matter of style, not C or C++.
 
You can pick a "random" file to show pretty much any form of dodgy
coding in the kernel code base! That doesn't change the fact that the
most common use of got in C code is, as Chris suggests, implementing
what amounts to finally clauses. C++ doesn't need them.
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Jan 25 08:12PM +0100

On 25/01/2020 02:19, Bart wrote:
> readability, or loss of localisation (eg. when you have to invent dummy
> functions etc to avoid use of goto) or things like that. (Or how much
> longer it takes to write such code.)
 
My code (especially my C code) is almost invariably written for
customers, and not something I can publish. Most code written by most
programmers is like that.
 
("Readability" is a somewhat subjective quality, and always a balance
between different factors, so I don't want to sound like my way of
coding is the only way. I code in the way that gives the best
readability for the type of programming tasks I handle, with
consideration for the customers and colleagues I have - I don't say my
styles and habits are universally applicable. Well, not /all/ of them,
anyway.)
 
 
> I can only repeat that the Linux kernel seems to use a lot, about
> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
 
You can repeat it until you are blue in the face - it is irrelevant for
any purpose other than showing that at least some large C projects use a
lot of gotos. Personally, I am not particularly fond of some of the
coding styles I have seen in the Linux kernel.
 
 
> Or C++; as I said earlier, it's not clear how much C++ helps avoiding
> gotos compared with C. C++-style exceptions would be handled by longjmp
> in C? Then that wouldn't count as a goto.
 
You can probably take a guess at how much I use "longjmp". I don't
believe I have ever seen a case where I thought it was a remotely good
idea. (I am not a great fan of exceptions in C++ either - certainly not
for the kind of coding I do on small systems where failure is not an
option. They are okay in Python, but that's a different kind of language.)
 
C++ RAII through constructors and destructors is what avoids many of the
coding problems that are sometimes solved with "goto" in C. It is not
exceptions.
 
 
> On the subject of never using a common feature of a language (or
> development system), then I've never written a makefile. And in the last
> 1.7Kloc pure C module I wrote, I didn't use a single macro.
 
A difference here is that makefiles are not part of the C or C++
languages, while macros are. I don't know why you would mix these.
 
David Brown <david.brown@hesbynett.no>: Jan 25 08:14PM +0100

On 25/01/2020 12:57, Bart wrote:
 
>> That's also C.
 
> David Brown said:
 
>  "I can only ever remember /once/ using "goto" in C code..."
 
I have never used "goto" in C++ code. Does that help?
 
(It's easy to mix up when the discussion is about C, when it is about
C++, when it is about either, both, or a comparison of the two. It has
certainly got jumbled in this thread.)
David Brown <david.brown@hesbynett.no>: Jan 25 08:34PM +0100

On 25/01/2020 15:58, Bart wrote:
>          D;
>          goto L;
>       }
 
I'm not sure how C++ would help here - you can write horrible
unstructured code in most languages. (C++ is a bit more restrictive in
how much you can jump around in unstructured ways, but I don't think it
stops this one.) What /would/ help is to give the programmer a good
kick up the arse and send him back to try again. (Having a resource
acquisition and release, like the mutex lock, at different levels of
indentation is a sure sign of jumbled thinking.)
 
do {
bool reflush = false;
A;
for (...) {
B;
if (!C) {
D;
reflush = true;
break;
}
}
}
 
 
Maybe the structure should be a little different - I haven't thought
through the details (and in particular, I don't know the "for_each_pwq"
macro). But a boolean flag like this is free - the compiler will turn
it into a goto.
 
 
 
> in any C++ magic to help out. Rewriting 25MLoC is not a helpful
> suggestion...)
 
> ...
bool skip_e = false;
> skip_e = true;
> }
> }
 
if (!skip_e) {
> E;
}
> L:
> G;
 
There is nothing like this that can't be handled by a flag boolean or
two. But there might be better ways, depending on the details of the
code - including splitting things up into more than one function,
duplicating code, or other re-arrangements.
Bart <bc@freeuk.com>: Jan 25 07:56PM

On 25/01/2020 18:45, Ian Collins wrote:
 
> You asked the question, which you have snipped: "Or C++; as I said
> earlier, it's not clear how much C++ helps avoiding gotos compared with C."
 
> What do you have to say about my answer?
 
If DB can avoid using 'goto' in C for (I understand) several decades,
then he can do it for C++ too.
 
The purpose of my mentioning Linux sources is that there are a range of
programming styles even in C: Linux kernel may be a prolific user of
gotos, DB is at the other end of the scale, and I would say extreme
(actually you can't be more extreme without using a negative number of
gotos!).
 
I'm not convinced that C++ features such RAII, exceptions, destructors
and so on are enough to deal with all the use-cases of goto I listed
earlier in the sub-thread, or the ones I didn't think of.
 
So they cannot by themselves account for using for being able to use 0
gotos. It seems some people just don't like them, and go to extra
measures to avoid them. Note the word 'extra'.
 
BTW C, and by extension C++, contains flow control that IMO can be even
worse that goto when abused. Takes this code:
 
int a=1;
 
goto L;
if (a) {
puts("A");
} else {
L:
puts("B");
}
 
This should print "A", but because of the jump into the block, will show
"B". This is considered bad form. But you can do exactly the same
without the goto:
 
int a=1;
 
switch (1) // any value can be used
if (a) {
puts("A");
} else {
default:
puts("B");
}
 
Should unstructured switch statements like this be banned? Well, that's
not possible; people still need to use switch, and they will also come
up with use-cases for weird applications of it.
 
With goto, at least, you know that some underhand flow control is going on!
"Öö Tiib" <ootiib@hot.ee>: Jan 25 12:41PM -0800

On Saturday, 25 January 2020 16:58:49 UTC+2, Bart wrote:
 
...
 
> How would C++ help here, to avoid either that extra logic, or the use of
> that goto?
 
Actually C has quite sophisticated program flow control to what C++
basically adds only exceptions and destructors plus various cosmetics
like range based fors and lambdas.
 
> D;
> goto L;
> }
 
Lets say for(...) above is for(E;F;G) then:
 
do {
A;
for (E;F;G) {
B;
if (!C) {
D;
break;
}
}
} while (F);
 
But I would no refactor it unless there is some kind of need
because it just adds another check of F.
 
> L:
> G;
> } // end of function
 
Here if G is done by destructor it is basically:
 
if (A) {
B;
if (C) {
D;
return;
}
}
E;
} // end of function
 
 
 
 
> Any ideas? This one seems more about code-sharing. I'm still interested
> in any C++ magic to help out. Rewriting 25MLoC is not a helpful
> suggestion...)
 
There are no magic. It matters if we want the G to
be ran even when something else, like B, throws, then
the G should be in destructor in C++. Otherwise it is
a bug waiting to start manifesting.
Ian Collins <ian-news@hotmail.com>: Jan 26 09:49AM +1300

On 26/01/2020 08:56, Bart wrote:
 
>> What do you have to say about my answer?
 
> If DB can avoid using 'goto' in C for (I understand) several decades,
> then he can do it for C++ too.
 
I have also never knowingly used goto in C or C++ code.
 
 
> I'm not convinced that C++ features such RAII, exceptions, destructors
> and so on are enough to deal with all the use-cases of goto I listed
> earlier in the sub-thread, or the ones I didn't think of.
 
The are enough to deal with the vast majority of them. Good (or some my
say, obsessive) style will take care of the rest. I ran a quick line
count and there are about 1.1M non-blank lines in our goto free C++ code
base excluding headers which would add quite a bit more. So avoiding
goto can't be that hard, can it?
 
> measures to avoid them. Note the word 'extra'.
 
> BTW C, and by extension C++, contains flow control that IMO can be even
> worse that goto when abused.
 
You can misuse any idiom to write bad code. With goto, bad code comes
naturally.
 
--
Ian.
Bart <bc@freeuk.com>: Jan 25 09:33PM

On 25/01/2020 20:49, Ian Collins wrote:
> count and there are about 1.1M non-blank lines in our goto free C++ code
> base excluding headers which would add quite a bit more.  So avoiding
> goto can't be that hard, can it?
 
How can I respond to that?
 
I've already said I can't tell how much bigger, less readable, less
productive it might have been to code like that, how many extra
functions etc, compared with just using the odd goto.
 
For my part, I'm in a position where I can add new features [to the
langages I use] that can eliminate many of /my/ uses of goto.
 
Yet there are still quite a few, because it's not that easy. I'm not
preparated to sacrifice the clean lines of my code, add extra indent
levels, more functions etc just so I can say I don't use any gotos.
 
(Here's one recent feature that I'm trying out, based on someone's idea
in comp.lang.misc. First, the original code with goto:
 
case msg
when wm_syskeydown then
if wparam = vkf10 then
msg := wm_keydown
goto dokey
fi
...
when wm_keydown, wm_keyup then
dokey:
.... do other stuff with msg
 
And here's the same code using the 'recase' feature:
 
case msg
when wm_syskeydown then
if wparam = vkf10 then
msg := wm_keydown
recase wm_keydown
fi
...
when wm_keydown, wm_keyup then
.... do other stuff with msg
 
No 'goto' and no label. (And no extra bools, no extra indents, no extra
functions either.) But it doesn't cover all the ways that you may want
to share blocks of code in such kinds of statement. I'm still working on
an elegant way to express that that doesn't look worse than goto.)
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 25 12:07AM -0500

On 1/24/20 1:17 AM, Daniel wrote:
> Can someone explain what is the difference between is_standard_layout and is_pod, and why the latter is being deprecated in 2020?
 
"Scalar types, POD classes (Clause 9), arrays of such types and
cv-qualified versions of these types (3.9.3) are collectively called POD
types. ... Scalar types, standard-layout class types (Clause 9), arrays
of such types and cv-qualified versions of these types (3.9.3) are
collectively called standard-layout types." (3.9p9)
 
Scalar types are, by definition, both POS type and standard-layout
types. Therefore, it's only for classes that there's a difference.
 
"A POD struct 109 is a non-union class that is both a trivial class and
a standard-layout class, and has no non-static data members of type
non-POD struct, non-POD union (or array of such types). Similarly, a
POD union is a union that is both a trivial class and a standard-layout
class, and has no non-static data members of type non-POD struct,
non-POD union (or array of such types). A POD class is a class that is
either a POD struct or a POD union." (9p10).
 
A POD class is by definition a standard-layout class, but the reverse is
not true. A standard-layout class that is non-trivial or has non-static
non-POD data members will not qualify as a POD class.
 
Things that could make a standard-layout class non-trivial include (9p6):
1. A missing default ctor.
2. A non-trivial default constructor.
3. Not trivially copyable
 
Thing that would prevent a standard-layout class from being trivially
copyable include (9p6):
1. a non-trivial copy ctor
2. a non-trivial move ctor
3. a non-trivial copy assignment operator
4. a non-trivial move constructor
5. a non-trivial dtor.
 
A user-provided function is never trivial, and the same rules apply
recursively to both base classes and non-static data members (12.1p4,
12.4p5, 12.8p12, 12.8p25).
 
Note that POD classes can have base classes, static data members, and
member functions. A standard-layout class can have all of those things
and non-trivial special member functions.
aminer68@gmail.com: Jan 24 04:27PM -0800

Hello,
 
 
More about arabs..
 
 
I am a white arab, and I think arabs are smart people,
Babylonians of Irak were racially arabs, read about them here:
 
3,700-year-old Babylonian tablet rewrites the history of maths - and shows the Greeks did not develop trigonometry
 
Read more here:
 
https://www.telegraph.co.uk/science/2017/08/24/3700-year-old-babylonian-tablet-rewrites-history-maths-could/
 
 
Also read the following about Arabs:
 
 
Research: Arab Inventors Make the U.S. More Innovative
 
It turns out that the U.S. is a major home for Arab inventors. In the five-year period from 2009 to 2013, there were 8,786 U.S. patent applications in our data set that had at least one Arab inventor. Of the total U.S. patent applications, 3.4% had at least one Arab inventor, despite the fact that Arab inventors represent only 0.3% of the total population.
 
Read more here:
 
https://hbr.org/2017/02/arab-inventors-make-the-u-s-more-innovative
 
 
Even Steve Jobs the founder of Apple had a Syrian immigrant father called Abdul Fattah Jandal.
 
 
Read more here about it:
 
https://www.macworld.co.uk/feature/apple/who-is-steve-jobs-syrian-immigrant-father-abdul-fattah-jandali-3624958/
 
 
Thank you,
Amine Moulay Ramdane.
Ned Latham <nedlatham@woden.valhalla.oz>: Jan 24 06:55PM -0600

aminer68 wrote:
 
----snip----
 
> 3,700-year-old Babylonian tablet rewrites the history of maths -
> and shows the Greeks did not develop trigonometry
 
Bullshit. They weren't the first, is all.
 
The Babylonians weren't the first, either.
 
----snip----
aminer68@gmail.com: Jan 24 03:52PM -0800

Hello,
 
 
More about Haskell..
 
 
I have just taken a look at Haskell, and i think
i am more capable and Haskell is easy for me to learn,
but to be more efficient, here is what i have just discovered:
take a look at the following about Mvars of Haskell:
 
http://neilmitchell.blogspot.com/2012/06/flavours-of-mvar_04.html
 
 
It is with this primitive of Haskell that we call Mvar that you construct
a higher level abstractions so that for example to make a FIFO queue that
is "energy" efficient, also it permits to use it to
be able to signal other processes or threads, but here again we have to talk
about the side-effects of it, because by using Mvar this way
you will be exposed to deadlocks or lost of signals. So i think that Haskell is not that good, so if you add the following weakness of Haskell, so this
tell me that i have not to waste my time with Haskell, read more:
 
Functional programming: A step backward
 
Unlike imperative code, functional code doesn't map to simple language constructs. Rather, it maps to mathematical constructs.
 
We've gone from wiring to punch cards to assembler to macro assembler to C (a very fancy macro assembler) and on to higher-level languages that abstract away much of the old machine complexity. Each step has taken us a little closer to the scene in "Star Trek IV" where a baffled Mr. Scott tries to speak instructions into a mouse. After decades of progress in making programming languages easier for humans to read and understand, functional programming syntax turns back the clock.
 
Functional programming addresses the concurrency problem of state but often at a cost of human readability. Functional programmming may be entirely appropriate for many circumstances. Ironically, it might even help bring computer and human languages closer together indirectly through defining domain-specific languages. But its difficult syntax makes it an extremely poor fit for general-purpose application programming. Don't jump on this bandwagon just yet — especially for risk-averse projects.
 
 
Read more here:
 
https://www.javaworld.com/article/2078610/functional-programming--a-step-backward.html
 
 
Thank you,
Amine Moulay Ramdane.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)