Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121642 > unrolled thread

Why is Usenet dead?

Back to article view | Back to comp.lang.c++

Contents

  Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-16 10:47 +0000
    Re: Why is Usenet dead? ImperiusDamian <dgwrightauthor@gmail.com> - 2025-02-16 23:59 -0500
    Re: Why is Usenet dead? Stuart Redmann <DerTopper@web.de> - 2025-02-17 22:34 +0100
      Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-18 08:22 +0000
        Re: Why is Usenet dead? Phillip <nntp@fulltermprivacy.com> - 2025-02-18 14:21 -0500
          Re: Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-18 20:23 +0000
          Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-19 08:25 +0000
            Re: Why is Usenet dead? Phillip <nntp@fulltermprivacy.com> - 2025-02-19 10:29 -0500
              Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-19 15:41 +0000
              Re: Why is Usenet dead? David Brown <david.brown@hesbynett.no> - 2025-02-19 16:43 +0100
                Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-19 15:58 +0000
                  Re: Why is Usenet dead? Michael S <already5chosen@yahoo.com> - 2025-02-19 19:15 +0200
                    Re: Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-19 18:14 +0000
                    Re: Why is Usenet dead? scott@slp53.sl.home (Scott Lurndal) - 2025-02-19 18:20 +0000
                    Re: Why is Usenet dead? Paavo Helde <eesnimi@osa.pri.ee> - 2025-02-19 20:59 +0200
                    Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-20 08:51 +0000
                      Re: Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-20 17:39 +0000
                        Re: Why is Usenet dead? Paavo Helde <eesnimi@osa.pri.ee> - 2025-02-20 22:39 +0200
                          Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-21 10:24 +0000
                          Re: Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-21 12:13 +0000
                            Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-21 12:25 +0000
                        Re: Why is Usenet dead? Muttley@DastardlyHQ.org - 2025-02-21 10:23 +0000
                          Re: Why is Usenet dead? Mr Flibble <leigh@i42.co.uk> - 2025-02-21 12:12 +0000

Page 1 of 2  [1] 2  Next page →

#121642 — Why is Usenet dead?

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

/Flibble

[toc] | [next] | [standalone]

#121657

On 2/16/2025 5:47 AM, Mr Flibble wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#121661

Mr Flibble <leigh@i42.co.uk> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#121665

On Mon, 17 Feb 2025 22:34:48 +0100
Stuart Redmann <DerTopper@web.de> 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.

[toc] | [prev] | [next] | [standalone]

#121667

On 2/18/25 3:22 AM, Muttley@DastardlyHQ.org wrote:
> On Mon, 17 Feb 2025 22:34:48 +0100
> Stuart Redmann <DerTopper@web.de> 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.

-- 
Phillip
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[toc] | [prev] | [next] | [standalone]

#121668

On Tue, 18 Feb 2025 14:21:32 -0500, Phillip <nntp@fulltermprivacy.com>
wrote:

>On 2/18/25 3:22 AM, Muttley@DastardlyHQ.org wrote:
>> On Mon, 17 Feb 2025 22:34:48 +0100
>> Stuart Redmann <DerTopper@web.de> 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.

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

/Flibble

[toc] | [prev] | [next] | [standalone]

#121671

On Tue, 18 Feb 2025 14:21:32 -0500
Phillip <nntp@fulltermprivacy.com> wibbled:
>On 2/18/25 3:22 AM, Muttley@DastardlyHQ.org wrote:
>> On Mon, 17 Feb 2025 22:34:48 +0100
>> Stuart Redmann <DerTopper@web.de> 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.

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

[toc] | [prev] | [next] | [standalone]

#121672

On 2/19/25 3:25 AM, Muttley@DastardlyHQ.org wrote:
> On Tue, 18 Feb 2025 14:21:32 -0500
> Phillip <nntp@fulltermprivacy.com> wibbled:
>> On 2/18/25 3:22 AM, Muttley@DastardlyHQ.org wrote:
>>> On Mon, 17 Feb 2025 22:34:48 +0100
>>> Stuart Redmann <DerTopper@web.de> 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.
> 
> 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.

-- 
Phillip
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[toc] | [prev] | [next] | [standalone]

#121673

On Wed, 19 Feb 2025 10:29:04 -0500
Phillip <nntp@fulltermprivacy.com> wibbled:
>On 2/19/25 3:25 AM, Muttley@DastardlyHQ.org 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.

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.

[toc] | [prev] | [next] | [standalone]

#121674

On 19/02/2025 16:29, Phillip wrote:
> On 2/19/25 3:25 AM, Muttley@DastardlyHQ.org wrote:
>> On Tue, 18 Feb 2025 14:21:32 -0500
>> Phillip <nntp@fulltermprivacy.com> 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.
> 

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.

[toc] | [prev] | [next] | [standalone]

#121675

On Wed, 19 Feb 2025 16:43:27 +0100
David Brown <david.brown@hesbynett.no> 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.

[toc] | [prev] | [next] | [standalone]

#121676

On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

> On Wed, 19 Feb 2025 16:43:27 +0100
> David Brown <david.brown@hesbynett.no> 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.

[toc] | [prev] | [next] | [standalone]

#121678

On Wed, 19 Feb 2025 19:15:18 +0200, Michael S
<already5chosen@yahoo.com> wrote:

>On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
>Muttley@DastardlyHQ.org wrote:
>
>> On Wed, 19 Feb 2025 16:43:27 +0100
>> David Brown <david.brown@hesbynett.no> 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.

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

[toc] | [prev] | [next] | [standalone]

#121679

Michael S <already5chosen@yahoo.com> writes:
>On Wed, 19 Feb 2025 15:58:48 -0000 (UTC)
>Muttley@DastardlyHQ.org wrote:
>
>> On Wed, 19 Feb 2025 16:43:27 +0100
>> David Brown <david.brown@hesbynett.no> 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"?

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.

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

locales


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

[toc] | [prev] | [next] | [standalone]

#121680

On 19.02.2025 19:15, Michael S wrote:
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#121685

On Wed, 19 Feb 2025 19:15:18 +0200
Michael S <already5chosen@yahoo.com> 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.

[toc] | [prev] | [next] | [standalone]

#121686

On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), Muttley@DastardlyHQ.org
wrote:

>On Wed, 19 Feb 2025 19:15:18 +0200
>Michael S <already5chosen@yahoo.com> 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().

/Flibble

[toc] | [prev] | [next] | [standalone]

#121687

On 20.02.2025 19:39, Mr Flibble wrote:
> On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), Muttley@DastardlyHQ.org
> wrote:
> 
>> On Wed, 19 Feb 2025 19:15:18 +0200
>> Michael S <already5chosen@yahoo.com> 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.

[toc] | [prev] | [next] | [standalone]

#121689

On Thu, 20 Feb 2025 22:39:31 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 20.02.2025 19:39, Mr Flibble wrote:
>> On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), Muttley@DastardlyHQ.org
>> wrote:
>> 
>>> On Wed, 19 Feb 2025 19:15:18 +0200
>>> Michael S <already5chosen@yahoo.com> 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.

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.

[toc] | [prev] | [next] | [standalone]

#121691

On Thu, 20 Feb 2025 22:39:31 +0200, Paavo Helde <eesnimi@osa.pri.ee>
wrote:

>On 20.02.2025 19:39, Mr Flibble wrote:
>> On Thu, 20 Feb 2025 08:51:13 -0000 (UTC), Muttley@DastardlyHQ.org
>> wrote:
>> 
>>> On Wed, 19 Feb 2025 19:15:18 +0200
>>> Michael S <already5chosen@yahoo.com> 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.

/Flibble

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web