Friday, April 13, 2018

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 06:46AM -0700

>> acquire a sense that it is important to be precise in their use of
>> language.
 
> "Static polymorphism" is a far more precise term than "ad hoc polymorphism".
 
Neither term is more precise. They lie on different linguistic
axes, and so cannot be compared in a linear way.
 
However, "ad hoc polymorphism" is more descriptively accurate for
the case of overloaded functions. The adjective "static" does
not refer to the kind of polymorphism involved but to how it is
implemented. Overload resolution could just as well be done at
run time as at compile time. In a similar vein, calling a virtual
function can in some cases determine at compile time which
function to call, avoiding the need for an indirect ("dynamic")
dispatch. In the particular case of C++ overloaded functions, if
we are going to be linguistically fussy we should say something
like "ad hoc polymorphism with static resolution".
 
> That doesn't support your explanation. ;-)
 
I think the above exchange illustrates the point rather well.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 13 11:07PM +0200

On 13.04.2018 15:46, Tim Rentsch wrote:
 
>> "Static polymorphism" is a far more precise term than "ad hoc polymorphism".
 
> Neither term is more precise. They lie on different linguistic
> axes, and so cannot be compared in a linear way.
 
Precise by circumscriptions will always be a component of humankind.
Human life will always foretell precise; many on some of the
lamentations but a few to the scenario. Zenith by linguistic lies in the
study of semiotics along with the field of semiotics. Term is the most
yielding amygdala of mankind.
 
According to professor of reality Leon Trotsky, precise is the most
fundamental administration of humanity. Gravity produces gamma rays to
transmit plasmas. Interference oscillates to emit neutrinoes for
reprovers at denigration. Information of an altruist on the interloper
is not the only thing a neuron with the field of literature inverts; it
also catalyzes orbitals to advances for linguistic. If domains recount a
confluence at most of the allocutions, a quantity of lingual can be more
amicably acceded. The more textuality may be the probe, the more a
concession that is blithe in how much we forsake respondents or
advocates might surprisingly be the confrontationally indubitable depletion.
 
As I have learned in my theory of knowledge class, society will always
diagnose term. The same brain may transmit two different pendulums of
ingenuity to counteract the plasma. Despite the fact that the same
neutrino may receive two different gamma rays by particularism,
radiation processes a neuron by the affirmation. Simulation is not the
only thing the brain implodes; it also reproduces with precise. Precise
which demonstrates agreements to sophists changes linguistic which
countenances edification. By conceding disenfranchisements which
proceed, those in question adhere too on term.
 
As I have learned in my semiotics class, lingual is the most fundamental
avocation of human society. Simulation at the search for philosophy
implodes to produce information for inauguration. Although the same
gamma ray may catalyze two different pendulums of appreciation, the same
orbital may emit two different plasmas. a neutrino is not the only thing
radiation spins; it also processes pendulums on appetites with
linguistic. Because manifold retorts are arranged on precise, the
deliberate linguistic can be more impudently inaugurated. a plethora of
precise changes the contradiction that homogenizes by term.
 
Precise to paganism has not, and presumably never will be immense,
inflexible, and mournful. Still yet, knowing that the scrofulous
irreverence will be provision, nearly all of the admonishments of our
personal accusation at the speculation we substantiate pledge a
circumspection. If agriculturalists regret advocates but commandeer
aggregations, the responses involved acquiesce as well with term. Term
for dictators has not, and undoubtedly never will be eternal, bland, and
judicious. Why is linguistic so debauched to mastication? The response
to this question is that precise is pallid.
 
 
> the case of overloaded functions. The adjective "static" does
> not refer to the kind of polymorphism involved but to how it is
> implemented.
 
No, it refers to how it /can/ always be implemented.
 
That is a constraint that completely defines what the term refers to;
it's a self-defining term.
 
As opposed to the ad hoc "ad hoc" academic nonsense. Note regarding the
in context pejorative use of "academic": I have some of that background
since I've worked as a college lecturer, Norwegian "amanuensis" (not
sure what that's in English, assistant professor?). And I am not
affronted by my own use of the term, it's just realistic, to the point.
 
 
> like "ad hoc polymorphism with static resolution".
 
>> That doesn't support your explanation. ;-)
 
> I think the above exchange illustrates the point rather well.
 
You do?
 
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 13 11:44PM +0100

On 13/04/2018 22:07, Alf P. Steinbach wrote:
>> the case of overloaded functions.  The adjective "static" does
>> not refer to the kind of polymorphism involved but to how it is
>> implemented.
 
In the case of C++ "static polymorphism" refers to both function
overloading and parametric polymorphism (templates) so we do need
another term if we just want to refer function overloading in the
context of static polymorphism in C++. I don't like the term "ad hoc"
as it is a bit vague not adequately describing function overloading;
"signature polymorphism" might be a better name. Also bear in mind that
C++ is not an object oriented programming language: it is a
multi-paradigm general purpose programming language with OOP features.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 13 11:48PM +0100

On 13/04/2018 23:44, Mr Flibble wrote:
> "signature polymorphism" might be a better name.  Also bear in mind that
> C++ is not an object oriented programming language: it is a
> multi-paradigm general purpose programming language with OOP features.
 
Actually I have an even better name for the function overloading variant
of static polymorphism: "argument polymorphism" as function overloading
depends on type of function arguments supplied.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
bartc <bc@freeuk.com>: Apr 13 03:47PM +0100

On 13/04/2018 15:22, Tim Rentsch wrote:
 
> Bart is up to his usual trolling tricks of misrepresenting what
> other people say. I advocate writing short functions. I have
> never advocated making functions as short as possible.
 
This is what you posted in c.l.c:
 
> For comparison, here are some numbers from my currently active
> project:
 
> median length: 14 lines
 
<snip>
 
> Not the kind of numbers I like to see. But even in this scary
> environment, 24% of functions are five lines or fewer.
 
It certainly does appear as though minimising function length is some
sort of goal, and you seem pleased that a quarter of your functions are
not over five lines.
 
--
bartc
David Brown <david.brown@hesbynett.no>: Apr 13 05:08PM +0200

On 13/04/18 16:33, Tim Rentsch wrote:
> but then at end admit that you yourself follow the principle put
> forth. Next you'll be saying it's both a floor wax and a dessert
> topping. :)
 
Let me re-phrase a little...
 
You told Mr. Flibble that you disagreed with him, but gave no
justification or reasoning for it.
 
I wanted to know /why/ you disagreed - if it is from general principles,
or if you had specific examples in mind. I know why /I/ think "one
declaration per line" is a good rule of thumb but not an absolute rule,
but I was interested in /your/ reasoning.
 
From your other post, it seems to be that guiding principles such as
code clarity can override any specific stylistic rule. Is that a
reasonable summary?
jameskuyper@verizon.net: Apr 13 08:42AM -0700

On Wednesday, April 11, 2018 at 5:45:00 PM UTC-4, Chris M. Thomasson wrote:
 
> > Did you try that? I hope you realize that it doesn't actually work. Macro names are matched to entire tokens, and in thrd_create, thrd_ is only a part of the thrd_create token.
 
> Argh! For some reason I did not notice that. ;^o
 
> I will try it out anyway just for fun.
 
While I make no claim to being an expert (or even a novice) at writing
multi-threaded code, I see other problems, too. There are only 7
functions defined in the C standard with names that start with thrd_.
Even if thrd_t were compatible with pthread_t, the following pairs of
functions have problems not covered by that #define:
 
int thrd_create(thrd_t *thr, thrd_start_t func,
void *arg);
int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine) (void *), void *arg);
 
thrd_t thrd_current(void);
pthread_t pthread_self(void);
(the function interface matches, but the names aren't matched in the way
implied by your #define).
 
int thrd_join(thrd_t thr, int *res);
int pthread_join(pthread_t thread, void **retval);
 
int thrd_sleep(const struct timespec *duration,
struct timespec *remaining);
No manual entry for pthread_sleep
 
int pthread_yield(void);
void thrd_yield(void);
 
In fact, only thrd_detach() and thrd_equal() have counterparts with
exactly comparable interfaces whose names differ only by thrd_ <=>
pthread_.
 
The results are better when comparing the mtx_ functions with
pthread_mutex_ functions - there's only one incompatibility:
int mtx_init(mtx_t *mtx, int type);
int pthread_mutex_init(pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
 
Comparing the cnd_ and pthread_cond_ functions, we have only two incompatibilities:
int cnd_init(cnd_t *cond);
int pthread_cond_init(pthread_cond_t *restrict cond,
const pthread_condattr_t *restrict attr);
 
int cnd_wait(cnd_t *cond, mtx_t *mtx);
int pthread_cond_wait(pthread_cond_t *restrict cond,
pthread_mutex_t *restrict mutex);
 
I'm not clear about which pthreads functions, if any, correspond to the
tss_ functions.
Tim Rentsch <txr@alumni.caltech.edu>: Apr 13 07:19AM -0700

> count is fucktarded at worst and egregious at best. [...] Yes
> functional decomposition is very important but there is no magic
> LOC number past which a function becomes "too big".
 
Does this mean that if you were asked to operate under a set of
style constraints that required function bodies to be no more
than thirteen million lines long that you would object and insist
there be no fixed limit?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 13 12:54PM -0700

On 4/12/2018 3:26 PM, Chris M. Thomasson wrote:
 
> https://pastebin.com/raw/bJUbDmKy
 
> https://groups.google.com/d/topic/comp.lang.c/WPH7ed5uS4Y/discussion
 
> It does support stdatomic.h, but it does support a lot of threads.h
 
ARGH! I meant to write that:
 
It does NOT support stdatomic.h, but it does support a lot of threads.h.
 
Sorry about that non-sense. Sorry for any confusion it must have caused.
 
;^O
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 07:56AM -0700

On Thursday, April 12, 2018 at 8:17:03 PM UTC-4, bartc wrote:
> straightforward. And the exactly the same as if the function was:
 
> void fn(int a, int* b){a, b;}
> )
 
I had the thought referencing items with the trailing & would be
desirable to use pointers as reference, such as i& = 5;.
 
And in the case where there is no ambiguity, it could be used
without it, such as i = 5;.
 
It's not solidified yet, and I'm still contemplating it. I just
think there may be room for simplification here. The need to have
a reference and a pointer exist, but if there's a way to better
coordinate it that's what I'm after.
 
--
Rick C. Hodgin
Manfred <noname@invalid.add>: Apr 13 07:30PM +0200

On 4/13/2018 4:12 PM, Tim Rentsch wrote:
>> call-by-reference evaluation.
 
> I'm pretty sure FORTRAN used call by value-result, at least
> in the FORTRAN IV era which is when I learned FORTRAN.
 
My time with FORTRAN dates back a very long time ago (fortran 77 was the
one I learned), so I'm a bit rusty, but I'm positive I was taught it was
call by reference.
Both 'by reference' and 'by value-result' are very similar - in fact
they are designed to produce the same result in common circumstances.
Out of pure nostalgia I tried a simple shot at g77 and f95, which shows
that a call foo(3.0) would be allowed as long as the argument is not
modified, but it would crash at the first attempt to modify it.
 
This would suggest it behaves like call by reference - i.e. no copy is
made of the argument.
I still have a f77 manual somewhere, but honestly I have not opened it
for a long time.
legalize+jeeves@mail.xmission.com (Richard): Apr 13 04:30PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>My point was, I'd rather have one long function than a badly
>refactored version, if those were the only two choices.
 
Those aren't the only two choices and they never have been.
--
"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>
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 09:35AM -0700

On Wednesday, February 28, 2018 at 7:58:15 PM UTC-5, JiiPee wrote:
> afterLoop:
 
> I googled and this seems to be manys preferably way. I have this often.
> How would you break nested loops? Somebody said Substroup said this is ok.
 
In CAlive I addressed this in several ways:
 
flow {..} blocks:
https://groups.google.com/d/msg/caliveprogramminglanguage/pSV7rzGcIeE/Ix3pBmhsBgAJ
 
breakN keywords and named scope breaks:
https://groups.google.com/d/msg/caliveprogramminglanguage/LgkacYbwlpo/WIV7uEIhBQAJ
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 09:52AM -0700

On Friday, April 13, 2018 at 12:36:08 PM UTC-4, Rick C. Hodgin wrote:
> https://groups.google.com/d/msg/caliveprogramminglanguage/pSV7rzGcIeE/Ix3pBmhsBgAJ
 
> breakN keywords and named scope breaks:
> https://groups.google.com/d/msg/caliveprogramminglanguage/LgkacYbwlpo/WIV7uEIhBQAJ
 
In your example, it would look like this:
 
for outer (int i = 0; i < m; i++)
{
    for (int j = 0; j < n; j++)
{
         if (some condition)
{
             // Do something and break...
             break outer;
         }
    }
}
 
And to use a flow control block:
 
flow
{
for (int i = 0; i < m; i++)
{
   for (int j = 0; j < n; j++)
{
       if (some condition)
{
           // Do something and break...
           flowout;
       }
   }
}
}
 
You could also break out your code so it's not so indented:
 
flow
{
for (int i = 0; i < m; i++)
for (int j = 0; j < n; j++)
logic;
 
} logic {
{
    if (some condition)
{
        // Do something and break...
        flowout;
    }
}
}
 
This would breakout the logic portion with the loop portion more
visually, make it documentable, and reduce the indent potetially
significantly.
 
You could also, in the CAlive editor, click a GUI feature of the
editor and restore it all inline so you can see it and edit it
that way.
 
If you would like to help with the CAlive project, please contact me.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 13 07:37AM -0700

On Friday, April 13, 2018 at 10:31:42 AM UTC-4, Rick C. Hodgin wrote:
> and in truth."
 
> Do you know God? He wants to know you. Ask me for help in understanding
> why we need Jesus.
 
I, the real Rick C. Hodgin, did not write this post.
 
Please examine the headers to see that there is someone usurping my
identity (and without my permission). I post from Eternal September
and Google Groups only, and using the full email address with periods
"rick.c.hodgin@gmail.com" only. Examine the message headers and you
will discover the truth about who is posting which messages.
 
comp.lang.c++:
https://groups.google.com/d/msg/comp.lang.c++/XFYL_DPNAuE/lrVKK90GCAAJ
 
alg.os.development:
https://groups.google.com/d/msg/alt.os.development/7zX5si_Ec1M/5Vsh2vVaCgAJ
 
alt.lang.asm:
https://groups.google.com/d/msg/alt.lang.asm/iXignwXb1qo/5xPFFfcwCAAJ
 
--
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)