Thursday, June 20, 2019

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

Ian Collins <ian-news@hotmail.com>: Jun 21 09:09AM +1200

>> Saying someone suffers from spiritual corruption for
>> being what they are is an evil nasty thing to do.
 
> I feel this statement you've made needs addressing.
 
It does, by you and your kind accepting that your beliefs are just that,
beliefs, not fact.
 
> Consider these things, Ian. I am not lying to you. I am teaching
> you the truth..
 
You aren't teaching anything. You are spreading hate wrapped up in a
thin veneer of religion. You have no clue about the harm your kind's
baseless drivel can have on young people trying to come to terms with
who they are. I do.
 
Please stop spreading harm.
 
--
Ian
rick.c.hodgin@gmail.com: Jun 20 02:19PM -0700

On Thursday, June 20, 2019 at 5:09:48 PM UTC-4, Ian Collins wrote:
> baseless drivel can have on young people trying to come to terms with
> who they are. I do.
 
> Please stop spreading harm.
 
 
This statement you make here will turn into this one on Judgment
Day:
 
"Rick, why didn't you try harder? If you would've pushed
more! If you would've explained it a different way. If
you would've used more Bible verses, or less Bible verses,
then would the knowledge been received.
 
"WHY DIDN'T YOU TRY HARDER?!?!! HELL LASTS FOREVER!!! WHY
DIDN'T YOU TRY HARDER?!?!??!!"
 
Don't believe me, Ian. Muster up the will to say this honest
prayer and come to God Himself:
 
God, //IF// you are real, I want to know the truth. Show
me the truth //IF// you are real, so that I can know that
truth without question. I truly want to know the truth,
and do not want to be deceived.
 
If you can get to that point, God will do the rest.
 
--
Rick C. Hodgin
Keith Thompson <kst-u@mib.org>: Jun 20 02:55PM -0700

> On 20/06/2019 14:53, rick.c.hodgin@gmail.com wrote:
>> Jesus [SNIP]
 
> That is a straight up lie. [SNIP]
 
Ian, you know as well as anyone that Rick will not respond to
criticism. Replying just encourages him to continue posting.
Please don't add to the noise level by arguing with him in the
newsgroup. (You can email him if you want to communicate with him
without involving the rest of us.)
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Ian Collins <ian-news@hotmail.com>: Jun 21 10:11AM +1200

On 21/06/2019 09:55, Keith Thompson wrote:
> criticism. Replying just encourages him to continue posting.
> Please don't add to the noise level by arguing with him in the
> newsgroup.
 
Hate speech need to be confronted no matter where it appears.
 
I think the 20+ years I've been posting here should give me some
immunity from condescension.
 
--
Ian.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 09:51AM -0400

On 6/20/19 9:42 AM, G G wrote:
> in OOP, is this still best, or oop way of handling task needing to be done
> based on a value. i know, i'm sorry, i don't think i know enough yet
> to ask the question intelligently.
 
Yes, you do need to learn how to ask the question better. It depends
entirely upon the task that needs to be done, which you haven't
specified. There are certainly tasks for which an array of function
pointers is the best approach - but I have no idea whether the task you
want to perform is one of them. In C++, an array of pointers to function
objects might be a better approach; or maybe not, depending upon the
task to be done.
Bart <bc@freeuk.com>: Jun 20 03:02PM +0100

On 20/06/2019 14:51, James Kuyper wrote:
> want to perform is one of them. In C++, an array of pointers to function
> objects might be a better approach; or maybe not, depending upon the
> task to be done.
 
What's the difference between an array of function pointers, and an
array of pointers to function objects?
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 20 03:55PM +0100

David Brown <david.brown@hesbynett.no> writes:
<cut>
 
> You can't have "int ( *ptr[]) (void);" on its own, just as you can't
> define "int x[];" on its own, as the compiler doesn't know the number of
> elements. You have to have a size for the array, or an "extern".
 
You are making a C and C++ mixed reply so it's worth pointing out that
both
 
int x[];
int (*ptr[])(void);
 
are OK in C. Unless there is a further definition with a size, both
will be assumed to be 1-element arrays.
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Jun 20 05:37PM +0200

On 20/06/2019 16:55, Ben Bacarisse wrote:
> int (*ptr[])(void);
 
> are OK in C. Unless there is a further definition with a size, both
> will be assumed to be 1-element arrays.
 
Really? I had assumed it was a gcc extension, and didn't check for
details in the standard. It is unlikely to be good style, even if it is
allowed.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 20 06:28PM +0100

>> will be assumed to be 1-element arrays.
 
> Really? I had assumed it was a gcc extension, and didn't check for
> details in the standard.
 
No, it's standard C.
 
> It is unlikely to be good style, even if it is
> allowed.
 
Indeed. In fact I can't think of any purpose other than to allow old
code to pass. It's just a hang-over.
 
--
Ben.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 20 10:01PM +0100

On Thu, 20 Jun 2019 15:02:31 +0100
> > task to be done.
 
> What's the difference between an array of function pointers, and an
> array of pointers to function objects?
 
You would not normally keep an array of pointers to std::function
objects: you would keep an array of std::function objects.
std::function objects are class templates with a call operator which
hand off to a virtual function, whose "innards" are allocated on free
store, and they can take anything which is callable (they perform type
erasure). In particular they can take a closure - either a lambda
expression with captured variable(s) or the return value of std::bind.
 
lambda expressions which are not closures are implicitly convertible to
function pointers. I would use an array of function pointers where
there will be no closures and an array of std::function objects
otherwise, on the grounds of efficiency.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 02:34PM -0700

On Thursday, June 20, 2019 at 10:02:40 AM UTC-4, Bart wrote:
> > task to be done.
 
> What's the difference between an array of function pointers, and an
> array of pointers to function objects.
 
A function object is an object that has an overloaded operator():
 
int function(int a, int b) { return 5*a+b;}
 
class function_object{
const int multiplier;
public:
function_object(int mult) : multiplier(mult) {};
operator()(int a, int b) const { return multiplier*a + b; }
} five(5);
 
Note: this is untested code; I don't currently have access to a compiler
that I can used to check it, so it may contain some trivial errors.
Sorry.
 
function(3,4) and five(3,4) perform exactly the same calculation.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 02:35PM -0700

On Thursday, June 20, 2019 at 10:55:27 AM UTC-4, Ben Bacarisse wrote:
...
> int (*ptr[])(void);
 
> are OK in C. Unless there is a further definition with a size, both
> will be assumed to be 1-element arrays.
 
And they will be zero-initialized, which in the case of the function pointer, means it will be a null pointer.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 02:40PM -0700

On Thursday, June 20, 2019 at 1:29:11 PM UTC-4, Ben Bacarisse wrote:
> > allowed.
 
> Indeed. In fact I can't think of any purpose other than to allow old
> code to pass. It's just a hang-over.
 
One way it's used is to declare an array with an unspecified size and
external linkage, which can be useful if users don't need to know the
size, and it might change. Only in the module where that array is
actually defined does it have a known size.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 20 11:05PM +0100

On Thu, 20 Jun 2019 14:34:06 -0700 (PDT)
> that I can used to check it, so it may contain some trivial errors.
> Sorry.
 
> function(3,4) and five(3,4) perform exactly the same calculation.
 
A function object does not have to have an overloaded call operator. It
just has to have a call operator.
 
But why on earth would you keep an array of pointers to such things?
You would either keep an array of 'function_objects' since they only
have an int member or (if you were to allocate them on free store)
an array of std::unique_ptr<function_object>.
 
In practice you wouldn't do either of those things: if you had the
multiplier as a closure as above you would probably use an array of
std::function objects wrapping lambda expressions.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 20 11:07PM +0100


>> >>> You can't have "int ( *ptr[]) (void);" on its own, just as you can't
>> >>> define "int x[];" on its own, as the compiler doesn't know the number of
>> >>> elements. You have to have a size for the array, or an "extern".
 
This:-----------------------------------------------------------^
 
> external linkage, which can be useful if users don't need to know the
> size, and it might change. Only in the module where that array is
> actually defined does it have a known size.
 
The "it" I was referring to was the original it -- that form without a
size or extern. With a size in one translation unit and an extern in
another, it's not an uncommon C usage.
 
--
Ben.
scott@slp53.sl.home (Scott Lurndal): Jun 20 01:51PM


>I do not see that choice for comp.lang.c++.
 
>I'm guessing that I can't get an email for each post, or am I missing something?
 
>Is this because it is a (very) high traffic list?
 
It's probably because this is Usenet, not a "google group". Google mirrors it,
but doesn't control it.
 
https://en.wikipedia.org/wiki/Usenet
rh kramer <rhkramer@gmail.com>: Jun 20 11:28AM -0700

I wrote what I've enclosed in <quote>s below in my email client, and then tried to send it, and found out that I can't post from my email client, I have to come here to post. So, the problem of getting posts as emails is solved, but I guess I have to come to google to post. I may look into Usenet unless someone can recommend a real "mail list" for a C++ newbie. (A mail list suits me much better than a forum or IRC.)
 
<quote>

Thanks to all who replied!
 
I might post more details later, but I have the problem resolved for myself (I
don't fully understand why it is this way, and this first attempt at an
explanation of what I did may not be as clear as it could be):
 
There are two places where you can choose how email updates are sent -- one is
on the main page of the list you are viewing (e.g., comp.lang.c++) and the
other is on the list of all the groups I am subscribed to ("my groups",
accessed from what is apparently the googlegroups home page).
 
On the comp.lang.c++ page, you get to make the choice by clicking on the down
arrow next to (or part of) the icon that is a human torso (help text is "My
settings") and then choosing "Membership and email settings". This is the
place where I only got the three choices for comp.lang.c++ (not including
"Every new message"), but, for the other groups I belong to, I get the "Every
new message" choice.
 
On the "my groups" page, all 4 choices appear, although on some groups (e.g.,
"Announcements and Alerts" it seems I can't choose among all of them (even
though none of them appear to be grayed out). Update: I lied -- the choices I can't make are gray (instead of black) -- I didn't notice that the first time I looked.
 
Aside on Usenet newsgroups: It is helpful to know that some Google groups (like this one) are actually Usenet newsgroups, but I don't think I have the need to
subscribe to a Usenet newsgroup server as long as I can read, post, and reply
to such newsgroups via Googlegroups.
 
Thanks to all who replied!
 
</quote>
 
On Thursday, June 20, 2019 09:33:49 AM rh kramer wrote:
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 02:24PM -0700

On Thursday, June 20, 2019 at 9:52:01 AM UTC-4, Scott Lurndal wrote:
 
> It's probably because this is Usenet, not a "google group". Google mirrors it,
> but doesn't control it.
 
> https://en.wikipedia.org/wiki/Usenet
123456789012345678901234567890123456789012345678901234567890123456789012
If that were the case, then I would also be unable to select that option
for this group. The key issue seems to be that you get one more option
if you go to "My groups" than if you select the down arrow on the
personal settings button.
Paavo Helde <myfirstname@osa.pri.ee>: Jun 20 05:30PM +0300

On 20.06.2019 16:28, Tim Rentsch wrote:
> (<aside>A default of only 1MB for the stack is -- please excuse
> my emphatic comment -- inexcusable in this day and age, and was
> even 20 years ago.</aside>)
 
I remember I once tried to raise the stack size to 20 MB and my
colleagues were very upset when the programs started to run out of
virtual address space when trying to create about 100 threads.
 
To be honest, this was in the era of 32-bit programs (but still less
than 20 years back!). 64-bit address space is supposed to take away such
worries, but for example the current x86-64 actually supports only
48-bit virtual address space, which is only 65,000 times more - not so
infinite as it first feels.
David Brown <david.brown@hesbynett.no>: Jun 20 05:34PM +0200

On 20/06/2019 15:28, Tim Rentsch wrote:
 
> I think there is another lesson here that is worth pointing out.
> The difficulty in this case is not recursion but using linear
> recursion rather than logarithmic recursion.
 
That is a very good point.
 
> depth that is logarithmic in N rather than linear in N. (Doing
> this also gives a significant performance improvement in cases
> where multiple-precision arithmetic is involved.)
 
A fun challenge with this sort of thing is deciding how to split up the
calculations most efficiently. I did a quick test (using Python,
because it has large number support effortlessly) and saw a difference
in splitting strategies. Method 1 was:
 
Π(1, 2, 3, 4, 5, 6, 7, 8)
=> Π(1, 2, 3, 4) * Π(5, 6, 7, 8)
=> (Π(1, 2) * Π(3, 4)) * (Π(5, 6) * Π(7, 8))
 
Method 2 was:
 
Π(1, 2, 3, 4, 5, 6, 7, 8)
=> Π(1, 3, 5, 7) * Π(2, 4, 6, 8)
=> (Π(1, 5) * Π(3, 7)) * (Π(2, 6) * Π(4, 8))
 
This second split was 5% faster for 200000!. Pulling out powers of 2
here could probably speed things up some more and also allow memoizing.
 
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jun 20 08:57AM -0700

> (think of a mutex lock object). So it cannot be optimized away
> unless the compiler can really prove there is no change in
> observable behavior.
 
The statement in the last sentence is too strong. Consider the
following scenario. With a particular code transformation applied
(for example, removing an unused local object, along with its
constructor/destructor calls), the observable behavior is X. If
the transformation were not applied, the observable behavior might
be X or might be Y (depending, say, on the timing of some OS
process scheduling, but not otherwise distinguishable). It cannot
be shown that there will be no change in the observable behavior,
because there might have been. Even so, it's okay to transform
the code (and remove the unused local), because the untransformed
behavior X could have happened serendipitously, and there is no
way for the program to tell otherwise.
 
Admittedly, in practice this distinction is unlikely to make a
difference. In most cases it's hard to show that a change _might_
not happen without also showing that a change _will_ not happen.
But the mathematician part of my brain feels obliged to point out
the distinction, even if in practice it might make a difference
only very rarely.
"Öö Tiib" <ootiib@hot.ee>: Jun 20 08:55AM -0700

On Tuesday, 18 June 2019 12:13:56 UTC+3, Juha Nieminen wrote:
> Oftentimes (perhaps most usually) this feature is not needed in
> practical code, but sometimes it is.
 
> This cannot really be achieved with either std::vector or std::array.
 
Indeed. But that does not mean we need shared_ptr to raw array
either. We can use shared_ptr to std::array or std::vector like we
use just plain std::array or std::vector when we need non-shared
array.
 
> of it), or passing references/pointers around, which introduces the
> problem of "who is the last one to reference this data?" The original
> needs to exist for as long as any object references it.
 
I did not try to imply that I can somehow have shared ownership of
data without having reference counting. I meant that it is orthogonal
to choice of object data type. "Object" here is raw array versus
std::vector or std::array.
 
> Of course if the data is owned by one object only, and any other code
> only needs it temporarily (eg. only for the duration of one function
> call), the std::vector or std::array are probably the better choices.
 
Those are usually better choice than raw array. An array being
managed by shared_ptr for shared ownership (that is rarely needed)
does not make raw array suddenly better choice.
 
> provides. (Of course this is at the cost of everything that it does
> provide, such as its various assign() functions, size(), empty(),
> and so on and so forth.)
 
On the ultra rare cases (when that matters) we may want to take a
step back and to investigate why we are allocating/releasing arrays
in such very busy loop and/or we may want to take a step forward
and to consider non-standard things like alloca() or VLA for array.
On common cases it does not matter. There unique_ptr to raw
array adds complications without observable benefits.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jun 20 05:27PM +0200

Am 20.06.19 um 11:35 schrieb Juha Nieminen:
>>> }
 
>> Why should it fail?
 
> Because Data is not an inner class of AClass?
 
Ah, you refer to the 'const Data&'. It is an inner class of
AClass::Inner. And this is the scope of the function.
 
 
Marcel
woodbrian77@gmail.com: Jun 20 07:28AM -0700

Shalom
 
Twenty years ago I realized things weren't going well
for the US. Bill Clinton wasn't a very good President
and those that have followed haven't been either. So
with my back to the wall I started a company. It hasn't
been easy, but by the grace of G-d and with your help,
I can say -- so far so good.
 
I still need to find some users though. I'm willing to
spend 16 hrs/wk for six months on a project that uses my
software: https://github.com/Ebenezer-group/onwards
 
as part of the project. More info here:
http://webEbenezer.net/about.html
 
I look forward to serving the community with free services
for years to come.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
rick.c.hodgin@gmail.com: Jun 20 07:11AM -0700

> This Friday (June 21, 2019) I would like to invite all Christians
> to take time out of their evening and say a prayer for the people
> here in this Usenet group.
 
 
If you have something specific you would like to have prayed for,
please reply here or in private email.
 
--
Rick C. Hodgin
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)