Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> [...]
>>>>>>> Please take a look at this video carefully:
>>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>>>
>>>>> So do you have *explanation*?
>>>>
>>>> For what?
>>>>
>>>>> Why do you ask about negative primes?
>>>>
>>>> I didn't.
>>>>
>>>> Is there anything in the video that's relevant either to this newsgroup
>>>> or to this thread? If so, what?
>>>>
>>> Sorry, that was Ttim Rensch i replied, you just replied
>>> on something wasn't you asked for :P
>>
>> So you posted a link to a 20-minute video with no explanation, and
>> you're still unwilling to explain how or whether it's relevant.
>>
> It shows two things: math is connected to reality,
> and second, explains why strong AI is impossible :P

So it's not relevant to this thread or to this newsgroup.

This newsgroup discusses the C programming language. If you want to
discuss something unrelated to that, please find another place to do so.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-10-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> So it's not relevant to this thread or to this newsgroup.
>
> This newsgroup discusses the C programming language. If you want to
> discuss something unrelated to that, please find another place to do so.
>
It is relevant, as qustion was if prime numbers can be negative.
I haven't asked question, I just gave link that discuss prime
numbers and whether they can be considered negative...
iThis all started with question of whether unsigned integers
can be considered mathematical concept. Unswer is yes.
Natural set + zero.
--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

On 04/10/2021 07:04, Branimir Maksimovic wrote:
> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> [...]
>>>>>>> Please take a look at this video carefully:
>>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>>>
>>>>> So do you have *explanation*?
>>>>
>>>> For what?
>>>>
>>>>> Why do you ask about negative primes?
>>>>
>>>> I didn't.
>>>>
>>>> Is there anything in the video that's relevant either to this newsgroup
>>>> or to this thread? If so, what?
>>>>
>>> Sorry, that was Ttim Rensch i replied, you just replied
>>> on something wasn't you asked for :P
>>
>> So you posted a link to a 20-minute video with no explanation, and
>> you're still unwilling to explain how or whether it's relevant.
>>
> It shows two things: math is connected to reality,
> and second, explains why strong AI is impossible :P
>

No, it does not show either of these two things. Have you actually
/watched/ it yourself?

Neither of these two points has anything to do with C. Nothing in the
video has anything to do with C. It is completely unrelated to anything
in this group, except for the one thread that was precisely about C code
for implementing the mathematics in the Collatz Conjecture.

It is an interesting and worthwhile video, IMHO, and I had watched it
previously. But this is a newsgroup for C, not a group for interesting
and worthwhile videos (even imagining that there could be a consensus on
what is interesting in a video).

On 2021-10-04, David Brown <david.brown@hesbynett.no> wrote:
> On 04/10/2021 07:04, Branimir Maksimovic wrote:
>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>>> [...]
>>>>>>>> Please take a look at this video carefully:
>>>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>>>
>>>>>>> Why?
>>>>>>>
>>>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes
>>>>>>> long.)
>>>>>>>
>>>>>> So do you have *explanation*?
>>>>>
>>>>> For what?
>>>>>
>>>>>> Why do you ask about negative primes?
>>>>>
>>>>> I didn't.
>>>>>
>>>>> Is there anything in the video that's relevant either to this newsgroup
>>>>> or to this thread? If so, what?
>>>>>
>>>> Sorry, that was Ttim Rensch i replied, you just replied on something
>>>> wasn't you asked for :P
>>>
>>> So you posted a link to a 20-minute video with no explanation, and you're
>>> still unwilling to explain how or whether it's relevant.
>>>
>> It shows two things: math is connected to reality, and second, explains why
>> strong AI is impossible :P
>>
>
> No, it does not show either of these two things. Have you actually /watched/
> it yourself?
>
> Neither of these two points has anything to do with C. Nothing in the video
> has anything to do with C. It is completely unrelated to anything in this
> group, except for the one thread that was precisely about C code for
> implementing the mathematics in the Collatz Conjecture.
>
> It is an interesting and worthwhile video, IMHO, and I had watched it
> previously. But this is a newsgroup for C, not a group for interesting and
> worthwhile videos (even imagining that there could be a consensus on what is
> interesting in a video).
>
>
Look when you speaking about numbers and relation of C types to numbers
it is relevant...

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
[...]
> Look when you speaking about numbers and relation of C types to numbers
> it is relevant...

You replied to a post that discussed signed and unsigned types.
You posted a link to a Youtube video and said nothing else about it.
You said nothing about C, and as far as I can tell the video said
nothing about C.

If you're going to post an Youtube or similar link, *at least* say
something about it. Nobody wants to spend 20 minutes watching something
just in case there's something relevant.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-10-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>> Look when you speaking about numbers and relation of C types to numbers
>> it is relevant...
>
> You replied to a post that discussed signed and unsigned types.
> You posted a link to a Youtube video and said nothing else about it.
> You said nothing about C, and as far as I can tell the video said
> nothing about C.
>
> If you're going to post an Youtube or similar link, *at least* say
> something about it. Nobody wants to spend 20 minutes watching something
> just in case there's something relevant.
>
Thanks, I'll remember that, and correct my behavior.

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>
>> Look when you speaking about numbers and relation of C types to numbers
>> it is relevant...
>
> You replied to a post that discussed signed and unsigned types.
> You posted a link to a Youtube video and said nothing else about it.
> You said nothing about C, and as far as I can tell the video said
> nothing about C.
>
> If you're going to post an Youtube or similar link, *at least* say
> something about it. Nobody wants to spend 20 minutes watching something
> just in case there's something relevant.

I have adopted a policy of not reading postings from Branimir
Maksimovic. This recent series of exchanges illustrates why.

Mehdi Amini <atorrses@gmail.com> writes:

> It seems these are some of changes for C23(C2x) standard taken from
> draft documents:
>
> https://en.cppreference.com/w/c/23
> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>
> What do you think of changes ?

My impression is that as time goes on C is looking more and more like
C++ and less and less like C. That's a bad trend.

On Wednesday, October 6, 2021 at 8:01:38 AM UTC-3, Tim Rentsch wrote:
> Mehdi Amini <ator...@gmail.com> writes:
>
> > It seems these are some of changes for C23(C2x) standard taken from
> > draft documents:
> >
> > https://en.cppreference.com/w/c/23
> > https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
> >
> > What do you think of changes ?
>
> My impression is that as time goes on C is looking more and more like
> C++ and less and less like C. That's a bad trend.

I don't think C is going that way. At least for now..
Do you have any proposal in mind to justify this?

One feature that may be in that direction is nullptr (but not approved yet)
not because it is complex but because it can create (like C++)
multiple ways to do the same thing creating a mess
in my opinion.
There are other more radical proposals but they are not approved yet.

On 2021-10-06, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> I have adopted a policy of not reading postings from Branimir
> Maksimovic. This recent series of exchanges illustrates why.
Well, I have added you to my Score file in Head as Well....

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

Le 06/10/2021 à 13:01, Tim Rentsch a écrit :
> Mehdi Amini <atorrses@gmail.com> writes:
>
>> It seems these are some of changes for C23(C2x) standard taken from
>> draft documents:
>>
>> https://en.cppreference.com/w/c/23
>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>
>> What do you think of changes ?
>
> My impression is that as time goes on C is looking more and more like
> C++ and less and less like C. That's a bad trend.

It's really far from it.

What makes you say that is probably that C borrows some "features" from
C++ at each new revision, but it's not a new trend.

The "features" it borrows from C++ are nothing that inherently makes C++
though, and IMO the majority of them are just things that were
long-awaited in C, without breaking the essence of C at all, and there's
no good reason to reinvent the wheel if those are already defined in C++.

With that said, from the C++ perspective, Bjarne Stroustrup (and
probably followed by the C++ committee) has always been, and still is, a
vehement proponent of fusing C into C++, making it a strict subset of
C++, instead of the current situation, with two different languages. Now
what kind of influence the C++ committee has over the C committee, I do
not know. I guess the main reason for including some C++ features into C
is the one I stated above: if C is going to get new features that are
similar to some that already exist in C++, why make them different and
further make the two languages divergent for no good reason?

Now, feel free to give relevant examples of C++ features that found
their way into C and which you think have no place there, with a
rationale. I'm all ears.

On 06/10/2021 19:07, Guillaume wrote:
> Le 06/10/2021 à 13:01, Tim Rentsch a écrit :
>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>>> It seems these are some of changes for C23(C2x) standard taken from
>>> draft documents:
>>>
>>> https://en.cppreference.com/w/c/23
>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>>
>>> What do you think of changes ?
>>
>> My impression is that as time goes on C is looking more and more like
>> C++ and less and less like C.  That's a bad trend.
>
> It's really far from it.
>
> What makes you say that is probably that C borrows some "features" from
> C++ at each new revision, but it's not a new trend.
>
> The "features" it borrows from C++ are nothing that inherently makes C++
> though, and IMO the majority of them are just things that were
> long-awaited in C, without breaking the essence of C at all, and there's
> no good reason to reinvent the wheel if those are already defined in C++.
>

That is absolutely the case, as I see it. There are several good
reasons for it. The C committee don't like adding new things to the
language unless they are /really/ sure they are a good idea. One way to
do that is to look at the practice from C++. Another is to look at
current C implementations with extensions - tools like gcc and clang
have a long history of letting some features flow between C and C++, if
they can be done without conflict. So in many cases, stretching back to
C99, the C committee have merely standardised C++ features that gcc had
already supported in C compilation. Low risk, low effort, and useful in
practice - what's not to like?

There are some people who stubbornly insist that C and C++ are
completely separate, and should progress independently. In reality,
mixes occur on a regular basis. Libraries or code gets written in C and
used in C++ projects - it's vital that most of what could reasonably be
expected to be in a C header, should also be valid and usable with C++
(possibly with an extern "C" wrapper). Real-world projects can often
start as C, and migrate towards C++ for new code - or they can be
started in C++ and borrow old C code. Toolchains support both
languages, and arbitrary differences just means more work. The same
applies to things like syntax highlighting editors. And in the MSVC
world, people writing C code generally use the C++ compiler because it
is (or has traditionally been) better than compiling as C.

> With that said, from the C++ perspective, Bjarne Stroustrup (and
> probably followed by the C++ committee) has always been, and still is, a
> vehement proponent of fusing C into C++, making it a strict subset of
> C++, instead of the current situation, with two different languages. Now
> what kind of influence the C++ committee has over the C committee, I do
> not know. I guess the main reason for including some C++ features into C
> is the one I stated above: if C is going to get new features that are
> similar to some that already exist in C++, why make them different and
> further make the two languages divergent for no good reason?
>
> Now, feel free to give relevant examples of C++ features that found
> their way into C and which you think have no place there, with a
> rationale. I'm all ears.
>

One proposal that I can think of is lambdas - there have been proposals
to add these to C, and these really don't seem a good fit to me. One
source of many of these ideas is Jens Gustedt, who is one of the few C
standards committee members who has a significant public internet
presence with his blog, and is quite prolific with his ideas and
proposals. Some of his ideas come from C++, others are new to both
languages. (Most C committee members are more anonymous, at least
compared to the C++ committee. That is quite appropriate for a language
that changes slowly and values stability so highly.) Of course Jens is
free to bring up his ideas - that does not mean that they will be
accepted by the committee as a whole.

As to features that C has already copied from C++, rather than just
proposals, which don't fit the style and philosophy of C - I can't think
of any off-hand. Tim will have to give examples himself.

Le 07/10/2021 à 11:06, David Brown a écrit :
> One proposal that I can think of is lambdas - there have been proposals
> to add these to C, and these really don't seem a good fit to me.

Yeah. Absolutely. I'm already not sure they are a good fit for C++, but
then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I
think it's eventually going to collapse under its own weight.

Jens Gustedt has a lot of interesting ideas from what I've read, but
he's a researcher. I'll take the practicality of his proposals with a
pinch of salt.

On 07/10/2021 19:31, Guillaume wrote:
> Le 07/10/2021 à 11:06, David Brown a écrit :
>> One proposal that I can think of is lambdas - there have been proposals
>> to add these to C, and these really don't seem a good fit to me.
>
> Yeah. Absolutely. I'm already not sure they are a good fit for C++, but
> then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I
> think it's eventually going to collapse under its own weight.
>

I like lambdas, and I'm glad C++ supports them.

But I agree that there are risks in the feature growth of C++ - while
individual programmers are usually going to be happy with just a subset
of the features, different programmers are going to pick different
subsets, and people are inevitably going to find themselves faced with
code that is written in the language they "know" while still being alien
to them.

> Jens Gustedt has a lot of interesting ideas from what I've read, but
> he's a researcher. I'll take the practicality of his proposals with a
> pinch of salt.
>

I think it is important for a language to have many people involved -
including more theoretical researcher types and more practical types.

On Thursday, October 7, 2021 at 5:14:56 PM UTC-3, David Brown wrote:
> On 07/10/2021 19:31, Guillaume wrote:
> > Le 07/10/2021 à 11:06, David Brown a écrit :
> >> One proposal that I can think of is lambdas - there have been proposals
> >> to add these to C, and these really don't seem a good fit to me.
> >
> > Yeah. Absolutely. I'm already not sure they are a good fit for C++, but
> > then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I
> > think it's eventually going to collapse under its own weight.
> >
> I like lambdas, and I'm glad C++ supports them.

The difficult (and I believe controversial) part in C is capture and how to store
lambda on heap for instance. It also requires the feature "auto" to work.

Here we can find how it is suppose to work in c here:
https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my

The amount of code to create a lambda and store on heap is similar of
the amount of the code we have today without this feature.
So, I am not convinced yet that C needs lambda capture.

I miss Lambdas a lot in my C code. Lambdas without capture would be fine for me.
The syntax and feature I would be happy is:

(void (void* data) ) { printf("hi!"); }

It if very similar of compound literal of function pointer.

(void (void (*) data) ) { 0 }

The difference it creates a compound literal that is a function itself.

I have implemented this at my transpiler

Select "Function Literal"
http://thradams.com/web2/cprime.html

On Friday, October 8, 2021 at 10:18:29 AM UTC-3, Thiago Adams wrote:
> On Thursday, October 7, 2021 at 5:14:56 PM UTC-3, David Brown wrote:
> > On 07/10/2021 19:31, Guillaume wrote:
> > > Le 07/10/2021 à 11:06, David Brown a écrit :
> > >> One proposal that I can think of is lambdas - there have been proposals
> > >> to add these to C, and these really don't seem a good fit to me.
> > >
> > > Yeah. Absolutely. I'm already not sure they are a good fit for C++, but
> > > then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I
> > > think it's eventually going to collapse under its own weight.
> > >
> > I like lambdas, and I'm glad C++ supports them.
> The difficult (and I believe controversial) part in C is capture and how to store
> lambda on heap for instance. It also requires the feature "auto" to work.
>
> Here we can find how it is suppose to work in c here:
> https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my
>
> The amount of code to create a lambda and store on heap is similar of
> the amount of the code we have today without this feature.
> So, I am not convinced yet that C needs lambda capture.
>
> I miss Lambdas a lot in my C code. Lambdas without capture would be fine for me.
> The syntax and feature I would be happy is:
>
> (void (void* data) ) { printf("hi!"); }
>
> It if very similar of compound literal of function pointer.
>
> (void (void (*) data) ) { 0 }
>
> The difference it creates a compound literal that is a function itself.
>
> I have implemented this at my transpiler
>
> Select "Function Literal"
> http://thradams.com/web2/cprime.html

I forgot to mention that lambdas in C++ also required addition of
return type.

[] (void) -> int

and mutable.

So lambdas with capture is a good example of how things can go bad in C.

On 20/09/2021 17:17, David Brown wrote:
> On 20/09/2021 17:41, John Bode wrote:

>> If signed integer representations other than two's complement will
>> no longer be supported, does this mean signed integer overflow can
>> have a well-defined behavior?  Or will it still be left undefined
>> to allow for optimizations?  Or could that be controlled with one
>> of these newfangled attribute thingies?
>
>
> No, signed integer overflow is still undefined behaviour - for which I
> am very glad. Defining it is terrible, IMHO, since any definition you
> give will be the wrong answer. Some would want it defined as wrapping
> ($DEITY knows why, since it is the silliest of all definitions despite
> being fairly efficient to implement), some would want it as an error or
> a trap, some would want saturation, some would want a NaN, some would
> want errno to be set.

Here's an example where signed wrapping came in useful. I wanted to do
this in a language (not C nor one of mine), where I knew integer
literals had int64 type, and need the largest value it could represent.

writeln(2**63-1)

It failed because it trapped integer overflow. So I couldn't do it.

If I tried it mine (I'd use C but it doesn't have a pow() op for integers):

println 2**63-1

it gave the expected answer. This briefly wraps one way (to int64.min),
then wraps the other way (to int64.max) to get the right answer.

Exactly the same thing that happens with unsigned:

println 2**64-1

This one wraps to 0 (uint64.min) then other way to uint.max. It is
useful behaviour for uint64; it is useful for int64.

But in both cases, you need to be aware of those temporary out-of-range
excursions, and not use the intermediate results as though they
represented natural arithmetic.

> My impression is that as time goes on C is looking more and
> more like C++ and less and less like C. That's a bad trend.

C should be dropped in favour of C++ for almost any project. With C
you have a dramatic less development-performance and make much more
bugs. If Chrome f.e. would be developed in C, it would be at least
five times the code and ten times the number of bugs.

On 2021-10-15, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> My impression is that as time goes on C is looking more and
>> more like C++ and less and less like C. That's a bad trend.
>
> C should be dropped in favour of C++ for almost any project. With C
> you have a dramatic less development-performance and make much more
> bugs. If Chrome f.e. would be developed in C, it would be at least
> five times the code and ten times the number of bugs.

So you reckon if you re-code the linux kernel in C++ it would be 5 times
less code and 10 times less buggy?

sssshhhh....

On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
[snip]
> If I tried it mine (I'd use C but it doesn't have a pow() op for
> integers):

That's a lame excuse, if I've ever heard one

>
> println 2**63-1

You /don't need/ "pow() for integers" to express 2^63 - 1 in C.

You could either hand expand 2^63 -1 into an integer, or, given an
integral type of 64 bits or larger, you simply use
(2ul<<63) - 1

as in
printf("%ul\n",(2ul<<63)-1);

[snip]
--
Lew Pitcher
"In Skills, We Trust"

On 15/10/2021 19:27, Lew Pitcher wrote:
> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
> [snip]
>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>> integers):
>
> That's a lame excuse, if I've ever heard one
>
>>
>> println 2**63-1
>
> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.

Yes, there are any number of ways of avoiding doing the work, namely
/working out/ 2**63-1 using signed integers and exponentiation or at
least multiplication.

I wanted the language to do it.

> You could either hand expand 2^63 -1 into an integer, or, given an
> integral type of 64 bits or larger, you simply use
> (2ul<<63) - 1

Now try that method for a ternary computer, using 39 bits (max
representable within int64).

On Fri, 15 Oct 2021 18:27:59 +0000, Lew Pitcher wrote:

> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
> [snip]
>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>> integers):
>
> That's a lame excuse, if I've ever heard one
>
>
>> println 2**63-1
>
> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.
>
> You could either hand expand 2^63 -1 into an integer, or, given an
> integral type of 64 bits or larger, you simply use
> (2ul<<63) - 1

Yah, I know. A thinko
I meant
(1ul<<63) - 1

>
> as in
> printf("%ul\n",(2ul<<63)-1);

printf("%ul\n",(1ul<<63)-1);

> [snip]

--
Lew Pitcher
"In Skills, We Trust"

On 15/10/2021 20:20, Lew Pitcher wrote:
> On Fri, 15 Oct 2021 18:27:59 +0000, Lew Pitcher wrote:
>
>> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
>> [snip]
>>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>>> integers):
>>
>> That's a lame excuse, if I've ever heard one
>>
>>
>>> println 2**63-1
>>
>> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.
>>
>> You could either hand expand 2^63 -1 into an integer, or, given an
>> integral type of 64 bits or larger, you simply use
>> (2ul<<63) - 1
>
> Yah, I know. A thinko
> I meant
> (1ul<<63) - 1
>

I was going to say that I don't like using shifts because I tend to get
it wrong.

And actually, this is still not right: it will only work when 'long'
happens to be 64 bits. It's likely to be 32 bits on Windows and 32-bit OSes.

1ULL is a better bet (together with a %lld format).

>> as in
>> printf("%ul\n",(2ul<<63)-1);
>
> printf("%ul\n",(1ul<<63)-1);
>
>> [snip]

Am 15.10.2021 um 18:50 schrieb Jim Jackson:
> On 2021-10-15, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> My impression is that as time goes on C is looking more and
>>> more like C++ and less and less like C. That's a bad trend.
>>
>> C should be dropped in favour of C++ for almost any project. With C
>> you have a dramatic less development-performance and make much more
>> bugs. If Chrome f.e. would be developed in C, it would be at least
>> five times the code and ten times the number of bugs.
>
> So you reckon if you re-code the linux kernel in C++ it would be 5 times
> less code and 10 times less buggy?

I think the Linux-kernel isn't such complex as Chrome.
But the code-size would be a fraction in C++.

On 10/15/2021 10:51 PM, Bonita Montero wrote:
> Am 15.10.2021 um 18:50 schrieb Jim Jackson:
>> On 2021-10-15, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> My impression is that as time goes on C is looking more and
>>>> more like C++ and less and less like C.  That's a bad trend.
>>>
>>> C should be dropped in favour of C++ for almost any project. With C
>>> you have a dramatic less development-performance and make much more
>>> bugs. If Chrome f.e. would be developed in C, it would be at least
>>> five times the code and ten times the number of bugs.
>>
>> So you reckon if you re-code the linux kernel in C++ it would be 5 times
>> less code and 10 times less buggy?
>
> I think the Linux-kernel isn't such complex as Chrome.

Really?

> But the code-size would be a fraction in C++.
>