Thursday, September 15, 2022

Digest for comp.lang.c++@googlegroups.com - 12 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Sep 15 05:35AM

>> others.
 
> Most people don't have your problem because they're not disordered
> like you. If you don't like my code don't read it.
 
You just love throwing insults at people who critique your code,
don't you?
 
I have said this many times before, and I'll say it again: I have no
idea why people here still keep taking you seriously and responding
to your every post. You do nothing but insult people who disagree
with your way of doing things.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 15 08:26AM +0200

Am 15.09.2022 um 07:35 schrieb Juha Nieminen:
 
>> like you. If you don't like my code don't read it.
 
> You just love throwing insults at people who critique your code,
> don't you?
 
You don't want to make factual criticism of my code, you want me to
follow your style. And that's where it's appropriate to say what the
problem is, which is that you have a mental disorder.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 15 05:43AM -0700

> idea why people here still keep taking you seriously and responding
> to your every post. You do nothing but insult people who disagree
> with your way of doing things.
 
What is it that you are hoping to accomplish by writing these
responses? If you have no idea why people keep responding to
his (or her) posts, why do you continue to respond to them?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 15 04:02PM +0200

Am 15.09.2022 um 14:43 schrieb Tim Rentsch:
 
> What is it that you are hoping to accomplish by writing these
> responses? If you have no idea why people keep responding to
> his (or her) posts, why do you continue to respond to them?
 
He is obsessed.
scott@slp53.sl.home (Scott Lurndal): Sep 15 02:09PM


>You don't want to make factual criticism of my code, you want me to
>follow your style. And that's where it's appropriate to say what the
>problem is, which is that you have a mental disorder.
 
Criticism of your propensity for complexity is perfectly appropriate.
 
K.I.S.S.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 15 04:56PM +0200

Am 15.09.2022 um 16:09 schrieb Scott Lurndal:
>> problem is, which is that you have a mental disorder.
 
> Criticism of your propensity for complexity is perfectly appropriate.
 
> K.I.S.S.
 
My code isn't complex but only has a differnt style.
I use a lot of functional programming to have sorter
or more performant code. This style is just uncommon.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 15 01:29PM -0700

On 9/13/2022 11:09 PM, Juha Nieminen wrote:
 
>> Do you mind if I quote that? I will give proper attributions of course,
>> Juha. :^)
 
> No need to attribute.
 
:^)
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 15 12:54AM +0100

On Wed, 14 Sep 2022 06:04:48 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
[snip]
> is complex enough as it is; it would not benefit from half the
> developers dropping off (and perhaps creating their own fork and
> going there).
 
Rust is entering the linux kernel on an experimental basis, after
receiving approval from Torvalds. If support hasn't yet been merged
into mainline (I am not sure if it has or it hasn't) it is about to be.
Make of it what you will. Presumably much of the Rust standard library
isn't available.
Juha Nieminen <nospam@thanks.invalid>: Sep 15 05:31AM

> into mainline (I am not sure if it has or it hasn't) it is about to be.
> Make of it what you will. Presumably much of the Rust standard library
> isn't available.
 
Let's hope that doesn't start a downspiral which starts by alienating
half of the current kernel developers.
 
Sometimes I think that Torvalds should relinquish control of his own
kernel, for its own good.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 15 10:19AM +0100

On Thu, 15 Sep 2022 05:31:58 -0000 (UTC)
> half of the current kernel developers.
 
> Sometimes I think that Torvalds should relinquish control of his own
> kernel, for its own good.
 
I don't think Torvalds was the originator of this: instead he has agreed
to see if it works out. Rust seems to have received sufficiently
widespread approbation within the kernel community as I understand it
and I don't think there is (at least at present) any requirement to use
or even know the language unless you are hacking on the particular
modules that use it.
 
I should have thought the experiment was worth the effort. Memory
errors are still a significant source of bugs and vulnerabilities, and
the promise that, by virtue of Rust's linear/affine type system, a
component that compiles is guaranteed to be memory correct as long as
the unsafe subset of Rust hasn't been used is quite a strong statement.
Michael S <already5chosen@yahoo.com>: Sep 15 12:15PM -0700

On Wednesday, September 14, 2022 at 3:21:17 PM UTC+3, Juha Nieminen wrote:
> style guideline page:
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
 
> (I'm not talking about the coding style itself, but the explanatory text.)
 
I like the language of this text.
Style itself - less so; agree or accept with 80%, but not with another 20%.
It seems, what you consider "professional language" I'd consider boring
and bureaucratic. Or, may be, not. In order to know for sure you have to
give me an example of what you consider well-written style guide.
 
Of course, there is another problem: anarchistic part of me dislikes
the whole idea of style guides so when style guide is written in mundane
style it just adds insult to the injury.
 
On the other hand "mundane" style is not the worst in my book, what drives
me more crazy is "wake" style. Fortunately, "wake" is more likely to be
encountered in "codes of conduct" and less likely in "style guides".
And since in my book "codes of conduct" are sort of humorous prose
anyway, even when athors have different intentions, their language
is inherently less damaging to my blood pressure.
 
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 15 07:18AM -0700


> But... why? Why do we suddenly stop at "If both operands have the
> same type..."? We have a pointer and a bool. How is that "the
> same type", even if you promote the bool to an integer?
 
It occurs to me that the problem here is not with the description
of additive operators (section 7.6.6) but with section 7.4, which
defines the usual arithmetic conversions. What we have in the
case of a pointer and a bool is not two operands but one operand,
that is, just the bool (remember that 7.6.6 p1 says "The usual
arithmetic conversions are performed for operands of arithmetic
or enumeration type", which is just the bool operand in this
case). Section 7.4 is written with the assumption that there
will be two operands being treated, but in this case there is
only one. Thus a solution is to revise 7.4 so it addresses the
more general scenario of converting one or more operands. Here
is a draft of a possible revision:
 
 
Many operators that expect one or more operands of arithmetic
or enumeration type cause conversions and yield result types in
a similar way. The purpose is to yield a common type, which is
also the type of the result. This pattern is called the usual
arithmetic conversions, which are defined as follows:
 
(1.1) -- If any operand is of scoped enumeration type no
conversions are performed; if any other operand does not have
the same type, the expression is ill-formed.
 
(1.2) -- If any operand is of type long double, all other
operands shall be converted to long double.
 
(1.3) -- Otherwise, if any operand is double, all other
operands shall be converted to double.
 
(1.4) -- Otherwise, if any operand is float, all other
operands shall be converted to float.
 
(1.5) -- Otherwise, the integral promotions shall be
performed on all operands. Then the following rules shall
be applied to the promoted operands:
 
(1.5.1) -- If all operands have the same type, no further
conversion is needed.
 
(1.5.2) -- Otherwise, if all operands have signed integer types
or all operands have unsigned integer types, all operands with
a type of lesser integer conversion rank shall be converted to
an operand type having the greatest integer conversion rank.
 
(1.5.3) -- Otherwise, if an operand that has unsigned integer
type has an integer conversion rank that is greater than or
equal to the rank of the type of all other operands, all other
operands shall be converted to the type of the unsigned integer
operand with the greatest integer conversion rank.
 
(1.5.4) -- Otherwise, if the type of the operand with signed
integer type can represent all of the values of the type of all
other operands, those operands shall be converted to the type
of the signed integer operand with the greatest integer
conversion rank.
 
(1.5.5) -- Otherwise, all operands shall be converted to the
unsigned integer type corresponding to the type of an operand
with signed integer type having the greatest integer conversion
rank.
 
2 If one operand is of enumeration type and any other operand
is of a different enumeration type or a floating-point type,
this behavior is deprecated.
 
Taking this approach solves the problem for section 7.6.6 and
also anticipates possible future additions to the language that
have more than two operands.
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)