Why is Usenet dead?

[Mr Flibble]

Because most of the users that remain are snowflakes that killfile
people with interesting things to say who, of course, mostly fuck off.

/Flibble

[ImperiusDamian]

Post by Mr Flibble
Because most of the users that remain are snowflakes that killfile
people with interesting things to say who, of course, mostly fuck off.
/Flibble

I only killfile spammers.

[Stuart Redmann]

Post by Mr Flibble
Because most of the users that remain are snowflakes that killfile
people with interesting things to say who, of course, mostly fuck off.
/Flibble

Well, Usenet is harder to get (need a provider, special app), less user
friendly (cannot attribute sections of text as code or add pictures), and
does not lure you in with fancy badges („you have earned the rank of senior
poster because you are still posting after two weeks“).

This is kind of fine, because most questions that used to be posted here
are mostly redundant („why is my base class method no longer visible in my
derived class?“), so we are not missing out on much. The lengthy
discussions here often contain stuff that I find highly interesting, and
you won’t get such discussions elsewhere (unless I’m missing something).

Sadly, there is a lot of name calling here, which adds unnecessary noise,
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I wished it
were (a).

Regards,
Stuart

[M***@DastardlyHQ.org]

On Mon, 17 Feb 2025 22:34:48 +0100

Post by Stuart Redmann
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I wished it
were (a).

Yes, I think unfortunately that the intersect between Python and C++ has
become much larger in recent years and some projects that would have been done
in C++ (or Java) are now done in Python because modern hardware means its now
fast enough despite being horribly inefficient and because of the miriad
libraries that allow lego brick plug and play style programming.

[Phillip]

Post by M***@DastardlyHQ.org
On Mon, 17 Feb 2025 22:34:48 +0100

Post by Stuart Redmann
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I wished it
were (a).

Yes, I think unfortunately that the intersect between Python and C++ has
become much larger in recent years and some projects that would have been done
in C++ (or Java) are now done in Python because modern hardware means its now
fast enough despite being horribly inefficient and because of the miriad
libraries that allow lego brick plug and play style programming.

I also think that because the python language is considered easier to
learn (which is probably subjective) that makes it more enticing for new
developers to get into.

[Mr Flibble]

Post by Phillip

Post by M***@DastardlyHQ.org
On Mon, 17 Feb 2025 22:34:48 +0100

Post by Stuart Redmann
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I wished it
were (a).

Yes, I think unfortunately that the intersect between Python and C++ has
become much larger in recent years and some projects that would have been done
in C++ (or Java) are now done in Python because modern hardware means its now
fast enough despite being horribly inefficient and because of the miriad
libraries that allow lego brick plug and play style programming.

I also think that because the python language is considered easier to
learn (which is probably subjective) that makes it more enticing for new
developers to get into.

You made any "Shark Tank"/"Dragon's Den" investments today, dear?

/Flibble

[M***@DastardlyHQ.org]

On Tue, 18 Feb 2025 14:21:32 -0500

Post by Stuart Redmann

Post by M***@DastardlyHQ.org
On Mon, 17 Feb 2025 22:34:48 +0100

Post by Stuart Redmann
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I

wished it

Post by M***@DastardlyHQ.org

Post by Stuart Redmann
were (a).

Yes, I think unfortunately that the intersect between Python and C++ has
become much larger in recent years and some projects that would have been

done

Post by M***@DastardlyHQ.org
in C++ (or Java) are now done in Python because modern hardware means its now
fast enough despite being horribly inefficient and because of the miriad
libraries that allow lego brick plug and play style programming.

I also think that because the python language is considered easier to
learn (which is probably subjective) that makes it more enticing for new
developers to get into.

I believe that its also used as a tutorial language on a lot of CS courses
now so there's a critical mass building up of people for whom its their
main or only (professional) programming language, and I have to admit that
for demonstrating basic CS concepts such as lists, dictionaries etc its a lot
more user friendly that C/C++.

[Phillip]

Post by M***@DastardlyHQ.org
On Tue, 18 Feb 2025 14:21:32 -0500

Post by Stuart Redmann

Post by M***@DastardlyHQ.org
On Mon, 17 Feb 2025 22:34:48 +0100

Post by Stuart Redmann
but it is easy to ignore. The fact that only few discussions are active at
the moment could either indicate that (a) C++ has developed in such a
favorable direction in recent years that there is little to complain about,
or (b) C++ is less and less popular. I‘m thinking it’s (b), but I

wished it

Post by M***@DastardlyHQ.org

Post by Stuart Redmann
were (a).

Yes, I think unfortunately that the intersect between Python and C++ has
become much larger in recent years and some projects that would have been

done

Post by M***@DastardlyHQ.org
in C++ (or Java) are now done in Python because modern hardware means its now
fast enough despite being horribly inefficient and because of the miriad
libraries that allow lego brick plug and play style programming.

I also think that because the python language is considered easier to
learn (which is probably subjective) that makes it more enticing for new
developers to get into.

I believe that its also used as a tutorial language on a lot of CS courses
now so there's a critical mass building up of people for whom its their
main or only (professional) programming language, and I have to admit that
for demonstrating basic CS concepts such as lists, dictionaries etc its a lot
more user friendly that C/C++.

Yeah, that doesn't surprise me. I mean, even back when I was first
getting into programming C wasn't my first language, I started on BASIC.
Python does do a very good job at visualizing things and it does make it
easier to show proofs so I do get why CS courses would use it. I just
wish more people would eventually graduate to C or C++ but most of them
don't because they don't see the need for it. That becomes a problem as
more of us retire and there aren't enough C programmers to replace us. A
lot of the world's deep foundational tech still runs on C and there
isn't any real movement to move away from it. We'll see what happens though.

[M***@DastardlyHQ.org]

On Wed, 19 Feb 2025 10:29:04 -0500

Post by Phillip

Post by M***@DastardlyHQ.org
On Tue, 18 Feb 2025 14:21:32 -0500
I believe that its also used as a tutorial language on a lot of CS courses
now so there's a critical mass building up of people for whom its their
main or only (professional) programming language, and I have to admit that
for demonstrating basic CS concepts such as lists, dictionaries etc its a lot
more user friendly that C/C++.

Yeah, that doesn't surprise me. I mean, even back when I was first
getting into programming C wasn't my first language, I started on BASIC.
Python does do a very good job at visualizing things and it does make it
easier to show proofs so I do get why CS courses would use it. I just
wish more people would eventually graduate to C or C++ but most of them
don't because they don't see the need for it. That becomes a problem as
more of us retire and there aren't enough C programmers to replace us. A
lot of the world's deep foundational tech still runs on C and there
isn't any real movement to move away from it. We'll see what happens though.

I suppose if you can get a job just knowing Python then there's not a lot of
reason to go and learn C and certainly not C++ with its almost vertical learning
curve for beginners. Also there's been a trend to higher level development
with plenty of libraries - sorry, "frameworks" - available to do most of the
dirty work. Which is fine, but IMO AI will eventually take over those kind
of lego brick coding tasks but it'll be quite a while before its writing
device drivers etc.

[David Brown]

Post by Phillip

Post by M***@DastardlyHQ.org
On Tue, 18 Feb 2025 14:21:32 -0500

Post by Phillip
I also think that because the python language is considered easier to
learn (which is probably subjective) that makes it more enticing for new
developers to get into.

I believe that its also used as a tutorial language on a lot of CS courses
now so there's a critical mass building up of people for whom its their
main or only (professional) programming language, and I have to admit that
for demonstrating basic CS concepts such as lists, dictionaries etc its a lot
more user friendly that C/C++.

Yeah, that doesn't surprise me. I mean, even back when I was first
getting into programming C wasn't my first language, I started on BASIC.
Python does do a very good job at visualizing things and it does make it
easier to show proofs so I do get why CS courses would use it. I just
wish more people would eventually graduate to C or C++ but most of them
don't because they don't see the need for it. That becomes a problem as
more of us retire and there aren't enough C programmers to replace us. A
lot of the world's deep foundational tech still runs on C and there
isn't any real movement to move away from it. We'll see what happens though.

There is a large amount of code that is written in C or C++, that would
have been better written in other languages - including Python. C in
particular has certain niche use-cases for which it is absolutely ideal,
but you often see people using it for tasks where it is completely
unnecessary and simply makes the whole thing harder or riskier. C++ is
suitable for a wider range of applications, but it too is often used in
situations where higher level languages could give greater developer
productivity, with fewer risks of bugs.

The world does not need more C programmers - the world needs a
continuous supply of people who can write good C code. Far too many
people who program in C don't do so very well - those people would be
better off programming in some other language.

[M***@DastardlyHQ.org]

On Wed, 19 Feb 2025 16:43:27 +0100

Post by David Brown
continuous supply of people who can write good C code. Far too many
people who program in C don't do so very well - those people would be
better off programming in some other language.

Often they're C++ programmers who didn't start out in C and so never had to
learn the messy world of pointers, managing memory yourself with malloc+free,
writing your own containers from scratch (the number of times I've had to
re-implement a doubly linked list when using pure C back in the day I've lost
count of), varargs (though I still use them in C++), scanf() etc.

[Michael S]

On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)

Post by M***@DastardlyHQ.org
On Wed, 19 Feb 2025 16:43:27 +0100

Post by David Brown
continuous supply of people who can write good C code. Far too many
people who program in C don't do so very well - those people would
be better off programming in some other language.

Often they're C++ programmers who didn't start out in C and so never
had to learn the messy world of pointers, managing memory yourself
with malloc+free, writing your own containers from scratch (the
number of times I've had to re-implement a doubly linked list when
using pure C back in the day I've lost count of), varargs (though I
still use them in C++), scanf() etc.

scanf() is as bad idea in C as it is in any other language.
When in C, always, but always, use strtol/strtod instead. Did I say
"always"?
std::from_chars() family, relatively recently added to C++ is a little
better functionally (not infected by locals), but worse because of
religious decision to use polymorphism in interface. Another minor
defect is use of reference.

Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.
Now, std::vector is a different story. It has real value and not
worth reimplementing. And not only due to functionality it provides,
but but also because people that read your code has easier time
understanding your intentions. Even more so std:map/std::set and
std:unordered_map.

[Mr Flibble]

On Wed, 19 Feb 2025 19:15:18 +0200, Michael S

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)

Post by M***@DastardlyHQ.org
On Wed, 19 Feb 2025 16:43:27 +0100

Post by David Brown
continuous supply of people who can write good C code. Far too many
people who program in C don't do so very well - those people would
be better off programming in some other language.

Often they're C++ programmers who didn't start out in C and so never
had to learn the messy world of pointers, managing memory yourself
with malloc+free, writing your own containers from scratch (the
number of times I've had to re-implement a doubly linked list when
using pure C back in the day I've lost count of), varargs (though I
still use them in C++), scanf() etc.

scanf() is as bad idea in C as it is in any other language.
When in C, always, but always, use strtol/strtod instead. Did I say
"always"?
std::from_chars() family, relatively recently added to C++ is a little
better functionally (not infected by locals), but worse because of
religious decision to use polymorphism in interface. Another minor
defect is use of reference.
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.
Now, std::vector is a different story. It has real value and not
worth reimplementing. And not only due to functionality it provides,
but but also because people that read your code has easier time
understanding your intentions. Even more so std:map/std::set and
std:unordered_map.

The only thing wrong with std::list is that splice() isn't gauranteed
to be O(1). That was a mistake, they should have made size() O(n)
instead to gaurantee constant time splice in all cases.

/Flibble

[Scott Lurndal]

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)

Post by M***@DastardlyHQ.org
On Wed, 19 Feb 2025 16:43:27 +0100

Post by David Brown
continuous supply of people who can write good C code. Far too many
people who program in C don't do so very well - those people would
be better off programming in some other language.

Often they're C++ programmers who didn't start out in C and so never
had to learn the messy world of pointers, managing memory yourself
with malloc+free, writing your own containers from scratch (the
number of times I've had to re-implement a doubly linked list when
using pure C back in the day I've lost count of), varargs (though I
still use them in C++), scanf() etc.

scanf() is as bad idea in C as it is in any other language.
When in C, always, but always, use strtol/strtod instead. Did I say
"always"?

For the most part, I concur. However, in my usage, strtoul/strtoull are
far more common than strtol; I very seldom use signed arithmetic
in my code.

Post by Michael S
std::from_chars() family, relatively recently added to C++ is a little
better functionally (not infected by locals)

locales

Post by Michael S
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Indeed, and it is fairly simple paradigm and useful to know.

I've seen C++-only programmers poo-poo using your own C linked list,
even if the C++ code that uses it was written prior to SGI developing
what became the C++ library.

[Paavo Helde]

Post by Michael S
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Too bad that std::list is the most useless of containers. std::deque has
always been a better fit in my use cases, but it is not so trivially
implementable. And the upcoming C++26 std::hive would probably be yet
better for some similar use cases.

[M***@DastardlyHQ.org]

On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

[Mr Flibble]

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

/Flibble

[Paavo Helde]

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

You can, for trivially relocatable types, which means most of the C++
value types even if they have non-trivial ctors and dtors. There is a
C++26 proposal for formalizing that concept
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2786r11.html).

Not sure if using specifically realloc would be a good idea though, I
guess with current trends of massive multithreading and fixed size
allocation pools there probably is no benefit in using realloc over an
explicit malloc+memcpy.

[M***@DastardlyHQ.org]

On Thu, 20 Feb 2025 22:39:31 +0200

Post by Paavo Helde

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

You can, for trivially relocatable types, which means most of the C++
value types even if they have non-trivial ctors and dtors. There is a
C++26 proposal for formalizing that concept
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2786r11.html).
Not sure if using specifically realloc would be a good idea though, I
guess with current trends of massive multithreading and fixed size
allocation pools there probably is no benefit in using realloc over an
explicit malloc+memcpy.

Even if on some kernel setup realloc() is no better, it still keeps your
code cleaner while being obvious to a maintenance coder what you're doing.

[Mr Flibble]

Post by Paavo Helde

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

You can, for trivially relocatable types, which means most of the C++
value types even if they have non-trivial ctors and dtors. There is a
C++26 proposal for formalizing that concept
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2786r11.html).
Not sure if using specifically realloc would be a good idea though, I
guess with current trends of massive multithreading and fixed size
allocation pools there probably is no benefit in using realloc over an
explicit malloc+memcpy.

std::vector value_type can be non-relocatable type ergo you cannot
implement std::vector in terms of realloc for all types ergo you
cannot implement std::vector in terms of realloc.

/Flibble

[M***@DastardlyHQ.org]

On Fri, 21 Feb 2025 12:13:48 +0000

Post by Mr Flibble

Post by Paavo Helde

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

You can, for trivially relocatable types, which means most of the C++
value types even if they have non-trivial ctors and dtors. There is a
C++26 proposal for formalizing that concept
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2786r11.html).
Not sure if using specifically realloc would be a good idea though, I
guess with current trends of massive multithreading and fixed size
allocation pools there probably is no benefit in using realloc over an
explicit malloc+memcpy.

std::vector value_type can be non-relocatable type ergo you cannot
implement std::vector in terms of realloc for all types ergo you
cannot implement std::vector in terms of realloc.

I very much doubt that the allocation code in vector is one size fits all,
that would be a ridiculous way to implement it.

[M***@DastardlyHQ.org]

On Thu, 20 Feb 2025 17:39:44 +0000

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

Sure youy can , its just an allocator that attempts to extend currently
allocated memory. Its absolutely what you'd use in a vector type for operations
like push_back though obviously its not the whole solution.

[Mr Flibble]

Post by M***@DastardlyHQ.org
On Thu, 20 Feb 2025 17:39:44 +0000

Post by Mr Flibble

Post by Mr Flibble
On Wed, 19 Feb 2025 19:15:18 +0200

Post by Michael S
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Reimplementing double-linked list is fine if all you need is
double-linked list. It does not take more than 20 minutes and typically
you end up with code that fits requirements better than when you
take it from somebody else.

Sure, its pretty simple. But a lot of younger C++ only coders wouldn't know
where to start if asked to do it. As for them implementing a dynamic array
using realloc(), pffft , forget it. Not that I'd bother now of course.

You cannot implement std::vector in terms of realloc().

Sure youy can , its just an allocator that attempts to extend currently
allocated memory. Its absolutely what you'd use in a vector type for operations
like push_back though obviously its not the whole solution.

No you cannot.

/Flibble