Because most of the users that remain are snowflakes that killfile
people with interesting things to say who, of course, mostly fuck off.
/Flibble
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).
On Mon, 17 Feb 2025 22:34:48 +0100
Stuart Redmann <[email protected]> wibbled:
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.
On 2/18/25 3:22 AM, [email protected] wrote:
On Mon, 17 Feb 2025 22:34:48 +0100
Stuart Redmann <[email protected]> wibbled:
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.
On 2/18/25 3:22 AM, [email protected] wrote:
On Mon, 17 Feb 2025 22:34:48 +0100
Stuart Redmann <[email protected]> wibbled:
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.
On 2/19/25 3:25 AM, [email protected] wrote:
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.
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.
On Tue, 18 Feb 2025 14:21:32 -0500
Phillip <[email protected]> wibbled:
On 2/18/25 3:22 AM, [email protected] wrote:
On Mon, 17 Feb 2025 22:34:48 +0100wished it
Stuart Redmann <[email protected]> wibbled:
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
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.
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++.
On 2/19/25 3:25 AM, [email protected] wrote:
On Tue, 18 Feb 2025 14:21:32 -0500
Phillip <[email protected]> wibbled:
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.
On Wed, 19 Feb 2025 16:43:27 +0100
David Brown <[email protected]> wibbled:
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.
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
[email protected] wrote:
On Wed, 19 Feb 2025 16:43:27 +0100
David Brown <[email protected]> wibbled:
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.
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.
On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
[email protected] wrote:
On Wed, 19 Feb 2025 16:43:27 +0100
David Brown <[email protected]> wibbled:
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)
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.
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.
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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.
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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().
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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().
On 20.02.2025 19:39, Mr Flibble wrote:
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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.
On 20.02.2025 19:39, Mr Flibble wrote:
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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.
On Thu, 20 Feb 2025 17:39:44 +0000
Mr Flibble <[email protected]> wibbled:
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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.
On Thu, 20 Feb 2025 22:39:31 +0200, Paavo Helde <[email protected]>
wrote:
On 20.02.2025 19:39, Mr Flibble wrote:
On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), [email protected]
wrote:
On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <[email protected]> wibbled:
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:47:18 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,778 |