Am 16.10.2021 um 20:50 schrieb Chris M. Thomasson:
> 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?

Think that Chrome would be at least five times the line-count if it
would be written in C. I bet it would be impossible to write stl like
Chrome in C. Look at the Oracle DB server: 25 mio lines of C and lots
of bugs fixed regulary. Such complex softare would be handled much
easier in C++.

Le 16/10/2021 à 07:51, Bonita Montero a écrit :
> I think the Linux-kernel isn't such complex as Chrome.
> But the code-size would be a fraction in C++.

First you need to tell us what you mean by code size.
To many people, "code size" is actually the size of the binary code. But
I suppose you are talking about source code here? (If we were talking
about binary code size, I'd venture that the opposite would be true. The
size would be likely to be significantly bigger.)

Anyway, this is a very common statement, regardless of the project, that
using C++ would invariably lead to fewer lines of code. But except for
small examples tailored just to show that, I have yet to see a formal
study clearly showing the point. And I have seen a lot of C++ projects
that were horribly bloated, unnecessarily complex and with a un
unreasonablme mess of class hierarchies.

But beyond that, does fewer lines of code always mean less coding effort
and easier maintenance? Not necessarily.

Feel free to rewrite the Linux kernel in C++ though. Or write your own
kernel with equivalent functionality. Don't forget to write it such that
it can survive 30 years without major rewrites every couple of years.
And we'll talk.

Am 16.10.2021 um 21:28 schrieb Guillaume:
> Le 16/10/2021 à 07:51, Bonita Montero a écrit :
>> I think the Linux-kernel isn't such complex as Chrome.
>> But the code-size would be a fraction in C++.
>
> First you need to tell us what you mean by code size.
> To many people, "code size" is actually the size of the binary code. But
> I suppose you are talking about source code here? (If we were talking
> about binary code size, I'd venture that the opposite would be true. The
> size would be likely to be significantly bigger.)

Yes, I'm talking about the LOCs.

> Anyway, this is a very common statement, regardless of the project, that
> using C++ would invariably lead to fewer lines of code. But except for
> small examples tailored just to show that, I have yet to see a formal
> study clearly showing the point. And I have seen a lot of C++ projects
> that were horribly bloated, unnecessarily complex and with a un
> unreasonablme mess of class hierarchies.

With C++ you've usually much less complexity.

On 2021-10-16, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 16.10.2021 um 20:50 schrieb Chris M. Thomasson:
>> 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?
>
> Think that Chrome would be at least five times the line-count if it
> would be written in C. I bet it would be impossible to write stl like
> Chrome in C. Look at the Oracle DB server: 25 mio lines of C and lots
> of bugs fixed regulary. Such complex softare would be handled much
> easier in C++.

Linux currently has about 27 million lines of code.

I think you may be right about C++ for many userland graphical programs.
Can you name an OS written in C++?

On 10/17/2021 6:04 AM, Bonita Montero wrote:
> Am 16.10.2021 um 21:28 schrieb Guillaume:
>> Le 16/10/2021 à 07:51, Bonita Montero a écrit :
>>> I think the Linux-kernel isn't such complex as Chrome.
>>> But the code-size would be a fraction in C++.
>>
>> First you need to tell us what you mean by code size.
>> To many people, "code size" is actually the size of the binary code.
>> But I suppose you are talking about source code here? (If we were
>> talking about binary code size, I'd venture that the opposite would be
>> true. The size would be likely to be significantly bigger.)
>
> Yes, I'm talking about the LOCs.

As Guillame said, this is not really a measure of code efficiency:

> But beyond that, does fewer lines of code always mean less coding effort and easier maintenance? Not necessarily.

>
>> Anyway, this is a very common statement, regardless of the project,
>> that using C++ would invariably lead to fewer lines of code. But
>> except for small examples tailored just to show that, I have yet to
>> see a formal study clearly showing the point. And I have seen a lot of
>> C++ projects that were horribly bloated, unnecessarily complex and
>> with a un unreasonablme mess of class hierarchies.
>
> With C++ you've usually much less complexity.

That is not properly accurate, I'd rephrase:

C++ is better equipped for managing complexity, yes.

But, depending on the problem domain, many problems get a simpler and
more efficient solution from C than C++.

Which is no surprise, it is in fact the reason for which C code can be
compiled by C++ compilers - in other words, the reason why C++ has been
thought of as a superset of C.

(If you limit yourself to Windows application programming then yes, C++
makes life easier than C does)

> Linux currently has about 27 million lines of code.
> I think you may be right about C++ for many userland graphical programs.
> Can you name an OS written in C++?

Symbian and Haiku.
That's not a matter of necesities that most operating systems are
written in C, that's just a matter of the writer's mindeset. Writing
an operating system in C++ would result in much less code and much
less bugs - if you use the language properly.

> But, depending on the problem domain, many problems get a simpler and
> more efficient solution from C than C++.

That's wrong. Its easier to structure all complex data-structures and
algorithms in C++.

On 17/10/2021 19:00, Bonita Montero wrote:
>> Linux currently has about 27 million lines of code.
>> I think you may be right about C++ for many userland graphical programs.
>> Can you name an OS written in C++?
>
> Symbian and Haiku.
> That's not a matter of necesities that most operating systems are
> written in C, that's just a matter of the writer's mindeset. Writing
> an operating system in C++ would result in much less code

Less code that /you/ have to write. Until you expand all those
templates. Overall, it might be a different picture.

That's assuming you make use of that ability to keep user-code shorter.

The examples I've seen of yours, is to take advantage of all those toys
to make user-code /more/ complicated.

On 10/17/2021 11:01 AM, Bonita Montero wrote:
>> But, depending on the problem domain, many problems get a simpler and
>> more efficient solution from C than C++.
>
> That's wrong. Its easier to structure all complex data-structures and
> algorithms in C++.
>

Its a lot easier to export a stable API in C. However, writing a kernel
in C++ is doable, but a bit tricky because you have to be extra careful.
Check this code out, NT 4.0 kernel, C galore... ;^)

https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos

I wonder what this would look like in C++. Humm... I wonder if they are
using C++ for Win11? Anybody know?

> Less code that /you/ have to write. Until you expand all
> those templates. Overall, it might be a different picture.

Do you think someone inspects the code expanded through templates ?
No one does that.

> The examples I've seen of yours, is to take advantage of all those
> toys to make user-code /more/ complicated.

That's wrong. C++ almost always results in simpler code.

On 18/10/2021 05:49, Bonita Montero wrote:
>> Less code that /you/ have to write. Until you expand all
>> those  templates. Overall, it might be a different picture.
>
> Do you think someone inspects the code expanded through templates ?
> No one does that.

It might be an issue if the resulting binary is several times the size
of the C equivalent.

>> The examples I've seen of yours, is to take advantage of all those
>> toys  to make user-code /more/ complicated.
>
> That's wrong. C++ almost always results in simpler code.

That was my point. It /could/ do (setting aside C++'s busy syntax). But
all examples of yours look like gobbledygook, even making use of those
libraries. It seems like you're just pulling in all those extra features
because you can.

>> Do you think someone inspects the code expanded through templates ?
>> No one does that.

> It might be an issue if the resulting binary is several times the size
> of the C equivalent.

Why should that be so ? The only thing that takes more space are the
tables for table-driven exception-handling, but this code isn't usually
executed. The other code is the same as you would write it manually in
C, but it takes much less time to write.

>> That's wrong. C++ almost always results in simpler code.

> That was my point. It /could/ do (setting aside C++'s busy syntax). But
> all examples of yours look like gobbledygook, ...

That's not true.
I've always received a lot of praise for my coding-style.

On 2021-10-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 16.10.2021 um 21:28 schrieb Guillaume:
>> Le 16/10/2021 à 07:51, Bonita Montero a écrit :
>>> I think the Linux-kernel isn't such complex as Chrome.
>>> But the code-size would be a fraction in C++.
>>
>> First you need to tell us what you mean by code size.
>> To many people, "code size" is actually the size of the binary code. But
>> I suppose you are talking about source code here? (If we were talking
>> about binary code size, I'd venture that the opposite would be true. The
>> size would be likely to be significantly bigger.)
>
> Yes, I'm talking about the LOCs.
>
>> Anyway, this is a very common statement, regardless of the project, that
>> using C++ would invariably lead to fewer lines of code. But except for
>> small examples tailored just to show that, I have yet to see a formal
>> study clearly showing the point. And I have seen a lot of C++ projects
>> that were horribly bloated, unnecessarily complex and with a un
>> unreasonablme mess of class hierarchies.
>
> With C++ you've usually much less complexity.
Yes, but you have to be carefull with C++ as it is not readable
and complex. Few people can understand it ...

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-17, Jim Jackson <jj@franjam.org.uk> wrote:
> On 2021-10-16, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 16.10.2021 um 20:50 schrieb Chris M. Thomasson:
>>> 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?
>>
>> Think that Chrome would be at least five times the line-count if it
>> would be written in C. I bet it would be impossible to write stl like
>> Chrome in C. Look at the Oracle DB server: 25 mio lines of C and lots
>> of bugs fixed regulary. Such complex softare would be handled much
>> easier in C++.
>
> Linux currently has about 27 million lines of code.
>
> I think you may be right about C++ for many userland graphical programs.
> Can you name an OS written in C++?
>

That would be interresting venture :P
>

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 2021-10-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Linux currently has about 27 million lines of code.
>> I think you may be right about C++ for many userland graphical programs.
>> Can you name an OS written in C++?
>
> Symbian and Haiku.
True Symbian is DEAD, let LIVE "Haiku :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

Am 21.10.2021 um 03:02 schrieb Branimir Maksimovic:
> On 2021-10-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 16.10.2021 um 21:28 schrieb Guillaume:
>>> Le 16/10/2021 à 07:51, Bonita Montero a écrit :
>>>> I think the Linux-kernel isn't such complex as Chrome.
>>>> But the code-size would be a fraction in C++.
>>>
>>> First you need to tell us what you mean by code size.
>>> To many people, "code size" is actually the size of the binary code. But
>>> I suppose you are talking about source code here? (If we were talking
>>> about binary code size, I'd venture that the opposite would be true. The
>>> size would be likely to be significantly bigger.)
>>
>> Yes, I'm talking about the LOCs.
>>
>>> Anyway, this is a very common statement, regardless of the project, that
>>> using C++ would invariably lead to fewer lines of code. But except for
>>> small examples tailored just to show that, I have yet to see a formal
>>> study clearly showing the point. And I have seen a lot of C++ projects
>>> that were horribly bloated, unnecessarily complex and with a un
>>> unreasonablme mess of class hierarchies.
>>
>> With C++ you've usually much less complexity.
> Yes, but you have to be carefull with C++ as it is not readable
> and complex. Few people can understand it ...

That depends on how you use it. But usually it's more
readable and if you use it properly it's impossible to
get the same readability in C.

Guillaume <message@bottle.org> writes:

> Le 06/10/2021 at 13:01, Tim Rentsch a ecrit:
>
>> 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?

None of the foregoing comments changes my reaction to the
proposal summary or my assessment of the trend.

> 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.

Given your statements above, what is my incentive for doing that?

Thiago Adams <thiago.adams@gmail.com> writes:

> 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? [...]

Forgive me for being blunt, but I find your postings idiotic.
I don't see any value in participating in that idiocy.

On 29/10/2021 13:04, Tim Rentsch wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> 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? [...]
>
> Forgive me for being blunt, but I find your postings idiotic.
> I don't see any value in participating in that idiocy.
>

Disagreeing with your out-of-the-blue statement and asking for examples
and justification is being "idiotic" ? Even by your usual low
standards, Tim, that is unreasonable.