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

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

"Nearly a quarter-century later, why is C++ still so popular?"

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

Contents

  "Nearly a quarter-century later, why is C++ still so popular?" Lynn McGuire <lynnmcguire5@gmail.com> - 2021-07-27 14:59 -0500
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-27 13:48 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-27 22:05 +0100
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 14:23 -0700
          Re: "Nearly a quarter-century later, why is C++ still so popular?" legalize+jeeves@mail.xmission.com (Richard) - 2021-08-05 19:49 +0000
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-08-19 20:08 +0000
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-08-19 18:20 -0700
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-20 06:13 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-08-20 06:17 +0000
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-08-20 00:03 -0700
                    Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-20 11:03 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" mickspud@downthefarm.com - 2021-08-20 15:19 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-20 14:26 +0200
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-29 23:40 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Cholo Lennon <chololennon@hotmail.com> - 2021-07-27 21:01 -0300
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-07-28 08:16 +0000
        Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-07-28 16:22 +0200
          Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-28 07:53 -0700
            Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-07-28 21:23 +0200
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-28 14:16 -0700
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-07-29 06:53 +0000
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-07-29 09:31 -0700
                Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_71i5@slwgrcbmd1l7yi1.org - 2021-07-30 11:21 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-01 08:28 +0000
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-01 05:49 -0700
                    Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-02 10:23 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_rLY23@_h_.co.uk - 2021-08-02 15:05 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-03 04:57 -0700
                        Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-03 12:16 +0000
                          Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-03 06:01 -0700
                            Re: "Nearly a quarter-century later, why is C++ still so popular?" Ian Collins <ian-news@hotmail.com> - 2021-08-08 13:03 +1200
                              Re: "Nearly a quarter-century later, why is C++ still so popular?" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-07 22:43 -0700
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-01 21:40 +0100
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-07-29 09:53 +0100
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Manfred <noname@add.invalid> - 2021-07-30 13:51 +0200
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Manfred <noname@add.invalid> - 2021-07-30 13:40 +0200
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-28 04:05 +0200
      Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_oyam9ltRb0@khlkg.info - 2021-07-28 09:30 +0000
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Bo Persson <bo@bo-persson.se> - 2021-07-28 08:19 +0200
    Re: "Nearly a quarter-century later, why is C++ still so popular?" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-03 13:10 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-03 18:37 -0500
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Cholo Lennon <chololennon@hotmail.com> - 2021-08-05 18:17 -0300
    Re:"Nearly a quarter-century later, why is C++ still so popular?" Blue Hat <blue_hat@hackershaven.com.jm> - 2021-08-08 13:33 -0500

Page 1 of 3  [1] 2 3  Next page →

#80744 — "Nearly a quarter-century later, why is C++ still so popular?"

"Nearly a quarter-century later, why is C++ still so popular?"
 
https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-so-popular/

"Despite C++’s downward trend on the TIOBE Programming Community index 
since 2001, the language’s fall from the coveted top two slots in 2020, 
vociferous and persistent claims that C++ is “dead like COBOL,” and the 
inroads the Rust is making in developer circles – C++ is still as 
viable, vital and relevant as ever."

Because it just works ?

And I am not impressed with Rust whatsoever.

Lynn

[toc] | [next] | [standalone]

#80745

In article <sdpojb$aq7$2@dont-email.me>,
 Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> Because it just works ?

Because too many people still think garbage collection is 
inefficient, and they can do better. See also Apple's dependence 
on reference counting and thus the inability to do generic graph 
data structures.

Object oriented programming and closures without mark/sweep 
collection is a bloody pain in the nethers. Hence C++ and its 
eternally broken finalisers.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#80746

On 27/07/2021 21:48, Siri Cruise wrote:
> In article <sdpojb$aq7$2@dont-email.me>,
>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> Because it just works ?
> 
> Because too many people still think garbage collection is
> inefficient, and they can do better. See also Apple's dependence
> on reference counting and thus the inability to do generic graph
> data structures.
> 
> Object oriented programming and closures without mark/sweep
> collection is a bloody pain in the nethers. Hence C++ and its
> eternally broken finalisers.
> 
But C++ doesn't have finalisers. That's a feature of GC languages.

Did you mean C#?

Andy

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

#80747

Vir Campestris <vir.campestris@invalid.invalid> writes:
> On 27/07/2021 21:48, Siri Cruise wrote:
>> In article <sdpojb$aq7$2@dont-email.me>,
>>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>> 
>>> Because it just works ?
>> Because too many people still think garbage collection is
>> inefficient, and they can do better. See also Apple's dependence
>> on reference counting and thus the inability to do generic graph
>> data structures.
>> Object oriented programming and closures without mark/sweep
>> collection is a bloody pain in the nethers. Hence C++ and its
>> eternally broken finalisers.
>> 
> But C++ doesn't have finalisers. That's a feature of GC languages.
>
> Did you mean C#?

C++ has destructors.  I suspect that's what Siri Cruise was referring to.

Saying that garbage collection is a substitute for destructors suggests
that memory is the only resource that needs to be managed.

-- 
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 */

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

#80779

[Please do not mail me a copy of your followup]

Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code
<871r7jih8h.fsf@nosuchdomain.example.com> thusly:

>Saying that garbage collection is a substitute for destructors suggests
>that memory is the only resource that needs to be managed.

I'd say that it also implies an incomplete/shallow understanding of
both destructors and garbage collection.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#80893

On Thu, 2021-08-05, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Keith Thompson <Keith.S.Thompson+u@gmail.com> spake the secret code
> <871r7jih8h.fsf@nosuchdomain.example.com> thusly:
>
>>Saying that garbage collection is a substitute for destructors suggests
>>that memory is the only resource that needs to be managed.
>
> I'd say that it also implies an incomplete/shallow understanding of
> both destructors and garbage collection.

I suspect the difference is higher up, on the design level.  When I
design my C++ code I pay attention to ownership and lifetime, and I
rarely or never find a need for garbage collection or reference
counting/shared_ptr.

Perhaps others optimize their designs for other aspects, and end up
with a legitimate need for those things.  And perhaps some libraries
and frameworks force such designs (for example, I don't do GUIs).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#80894

In article <slrnshtei9.5o3.grahn+nntp@frailea.sa.invalid>,
 Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> I suspect the difference is higher up, on the design level.  When I
> design my C++ code I pay attention to ownership and lifetime, and I
> rarely or never find a need for garbage collection or reference
> counting/shared_ptr.

Implement a directed graph with dynamic edges and nodes which has 
no naturally distinguished edges from back edges. Try to figure 
out how to pay careful enough attention to avoid reference 
tracing or counting. So do reference counting. Now when you 
delete an edge to a node, you have to check if it only receives 
back edges, and if so converts a back edge to an edge. This 
conversion has nothing to do with the directed graph itself but 
an artifact of reference counting.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#80895

Siri Cruise <chine.bleu@yahoo.com> wrote:
> Implement a directed graph with dynamic edges and nodes which has 
> no naturally distinguished edges from back edges. Try to figure 
> out how to pay careful enough attention to avoid reference 
> tracing or counting. So do reference counting. Now when you 
> delete an edge to a node, you have to check if it only receives 
> back edges, and if so converts a back edge to an edge. This 
> conversion has nothing to do with the directed graph itself but 
> an artifact of reference counting.

I can't think of a data structure where the elements require
reference counting, when those elements are solely used within
that data structure itself.

Usually GC or reference counting is needed when *something else*
may have a reference/pointer to the object that may last longer
than the data container.

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

#80896

On Fri, 2021-08-20, Siri Cruise wrote:
> In article <slrnshtei9.5o3.grahn+nntp@frailea.sa.invalid>,
>  Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> I suspect the difference is higher up, on the design level.  When I
>> design my C++ code I pay attention to ownership and lifetime, and I
>> rarely or never find a need for garbage collection or reference
>> counting/shared_ptr.
>
> Implement a directed graph with dynamic edges and nodes which has 
> no naturally distinguished edges from back edges.

No doubt there are scenarios where Java-style garbage collection is
the best solution -- it's just that I have never been in that
situation.

When I've done graphs, it has been enough to let a Graph object (or
just a std::set<Edge>) own everything.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#80897

In article <slrnshui7h.5o3.grahn+nntp@frailea.sa.invalid>,
 Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> On Fri, 2021-08-20, Siri Cruise wrote:
> > In article <slrnshtei9.5o3.grahn+nntp@frailea.sa.invalid>,
> >  Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> >
> >> I suspect the difference is higher up, on the design level.  When I
> >> design my C++ code I pay attention to ownership and lifetime, and I
> >> rarely or never find a need for garbage collection or reference
> >> counting/shared_ptr.
> >
> > Implement a directed graph with dynamic edges and nodes which has 
> > no naturally distinguished edges from back edges.
> 
> No doubt there are scenarios where Java-style garbage collection is
> the best solution -- it's just that I have never been in that
> situation.

Directed graphs are an ideal way of handling complex relations. 
Encode the relation into a graph; use Tarjan's algorithm to find 
strongly connected component; factor the graph by SCCs. The 
resulting reduced graph is a DAG which is the partial order with 
each SCC being an equivalence class. Do topological sorting on 
the DAG. You can then deal with the original relation equivalence 
class by equivalence class either from the sources or sinks. From 
the sinks means every edge in the SCC is to the same SCC or to a 
node of a previously processed equivalence class.

Many programming problems are about distributing information 
around a relation of nodes. The usual method is to find fix 
points on bit vectors.

> When I've done graphs, it has been enough to let a Graph object (or
> just a std::set<Edge>) own everything.

That just means someone else had to deal with back edges.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#80898

Siri Cruise <chine.bleu@yahoo.com> wrote:
> Directed graphs are an ideal way of handling complex relations. 
> Encode the relation into a graph; use Tarjan's algorithm to find 
> strongly connected component; factor the graph by SCCs. The 
> resulting reduced graph is a DAG which is the partial order with 
> each SCC being an equivalence class. Do topological sorting on 
> the DAG. You can then deal with the original relation equivalence 
> class by equivalence class either from the sources or sinks. From 
> the sinks means every edge in the SCC is to the same SCC or to a 
> node of a previously processed equivalence class.

If you need to be constantly adding and removing elements from that
graph during the runtime of the program, then sure, it's probably
best to allocate individual elements and handle them by reference
(ie. pointer). Or, if for some reason the elements can be of
different types.

However, if what you describe is "build the graph at startup and
then just read its contents during the execution of the program",
it may well be more efficient to put all the elements in one
single array, and then have connections between the elements
with pointers or indices. This requires no memory management
of any kind (other than, obviously, freeing the array when
the graph isn't needed anymore).

There might even be room for low-level optimization by
rearranging the elements in an optimal way in the array so
that they are accessed as linearly as possible in most cases.
(With individually allocated elements you cannot do this
kind of optimization even if you wanted to.)

Moreover, this approach allows for Data-Oriented Design.
If the graph nodes contain several member variables, and
usually you are only interested in particular ones, you could
do the DOD thing and split the elements into their own
arrays, further increasing cache locality.

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

#80900

On Fri, 20 Aug 2021 11:03:59 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Siri Cruise <chine.bleu@yahoo.com> wrote:
>> Directed graphs are an ideal way of handling complex relations. 
>> Encode the relation into a graph; use Tarjan's algorithm to find 
>> strongly connected component; factor the graph by SCCs. The 
>> resulting reduced graph is a DAG which is the partial order with 
>> each SCC being an equivalence class. Do topological sorting on 
>> the DAG. You can then deal with the original relation equivalence 
>> class by equivalence class either from the sources or sinks. From 
>> the sinks means every edge in the SCC is to the same SCC or to a 
>> node of a previously processed equivalence class.
>
>If you need to be constantly adding and removing elements from that
>graph during the runtime of the program, then sure, it's probably
>best to allocate individual elements and handle them by reference
>(ie. pointer). Or, if for some reason the elements can be of
>different types.
>
>However, if what you describe is "build the graph at startup and
>then just read its contents during the execution of the program",
>it may well be more efficient to put all the elements in one
>single array, and then have connections between the elements
>with pointers or indices. This requires no memory management
>of any kind (other than, obviously, freeing the array when
>the graph isn't needed anymore).

If only there was a standard library that came with C++ that had containers
that could do something like that.... hmmm....

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

#80899

On 20 Aug 2021 03:20, Siri Cruise wrote:
> In article <slrnshtei9.5o3.grahn+nntp@frailea.sa.invalid>,
>   Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> 
>> I suspect the difference is higher up, on the design level.  When I
>> design my C++ code I pay attention to ownership and lifetime, and I
>> rarely or never find a need for garbage collection or reference
>> counting/shared_ptr.
> 
> Implement a directed graph with dynamic edges and nodes which has
> no naturally distinguished edges from back edges. Try to figure
> out how to pay careful enough attention to avoid reference
> tracing or counting.

I don't see why one would have to think or pay attention to avoid 
reference counting for a directed graph.

Just use Boost Graph, or a DIY thing based on e.g. `std::vector`.

Is it that when you write “dynamic edges and nodes” you mean dynamically 
allocated node objects, with the edges represented as pointers to nodes?

We did that at college, early 1980's, finding shortest route between any 
two cities in Norway. We had one DEC Rainbow workstation to do color 
graphics on. Otherwise had to use HP monochrome graphics terminals :(

Anyway, if that's what you're thinking of then that is an inefficient 
way to do things. E.g. I doubt that Boost Graph does that internally. 
But even when that approach is adopted I still fail to see the alleged 
practical need for reference counting. The pointers are internal in the 
structure. They're not owning pointers. (In passing, for efficient 
removal of nodes just let each node keep a list of all edges to it, not 
just a list of all edges from it, but better: use Boost Graph).


> So do reference counting. Now when you
> delete an edge to a node, you have to check if it only receives
> back edges, and if so converts a back edge to an edge.

Huh? (Forgive me if I'm dumb here, not yet on first coffee.)


> This
> conversion has nothing to do with the directed graph itself but
> an artifact of reference counting.

Someone at one time gave a slightly similar (if I understood you) 
example that /actually/ required garbage collection, or else incurring 
some heavy complexity.

It was about function representations with parts of functions being 
referenced and reused with abandon.

The person who came up with it had a background in functional 
programming and hence, I believe, mathematics, and the example was 
convincing.


Cheers,

- Alf (BTDT)

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

#80903

On Friday, 20 August 2021 at 15:26:36 UTC+3, Alf P. Steinbach wrote:
> On 20 Aug 2021 03:20, Siri Cruise wrote: 
> > In article <slrnshtei9.5...@frailea.sa.invalid>, 
> > Jorgen Grahn <grahn...@snipabacken.se> wrote: 
> > 
> >> I suspect the difference is higher up, on the design level. When I 
> >> design my C++ code I pay attention to ownership and lifetime, and I 
> >> rarely or never find a need for garbage collection or reference 
> >> counting/shared_ptr. 
> > 
> > Implement a directed graph with dynamic edges and nodes which has 
> > no naturally distinguished edges from back edges. Try to figure 
> > out how to pay careful enough attention to avoid reference 
> > tracing or counting.
> I don't see why one would have to think or pay attention to avoid 
> reference counting for a directed graph. 
> 
> Just use Boost Graph, or a DIY thing based on e.g. `std::vector`. 
> 
> Is it that when you write “dynamic edges and nodes” you mean dynamically 
> allocated node objects, with the edges represented as pointers to nodes? 
> 
> We did that at college, early 1980's, finding shortest route between any 
> two cities in Norway. We had one DEC Rainbow workstation to do color 
> graphics on. Otherwise had to use HP monochrome graphics terminals :( 
> 
> Anyway, if that's what you're thinking of then that is an inefficient 
> way to do things. E.g. I doubt that Boost Graph does that internally. 
> But even when that approach is adopted I still fail to see the alleged 
> practical need for reference counting. The pointers are internal in the 
> structure. They're not owning pointers. (In passing, for efficient 
> removal of nodes just let each node keep a list of all edges to it, not 
> just a list of all edges from it, but better: use Boost Graph).

Typical graph manipulation libraries (like that Boost.Graph) allow parts of
graph to be simply disconnected from each other. There are no requirements
that when connecting edge is missing (or was erased) then also the whole
disconnected part must be removed. Perhaps Siri implied such requirement? 

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

#80748

On 7/27/21 5:48 PM, Siri Cruise wrote:
> In article <sdpojb$aq7$2@dont-email.me>,
>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> Because it just works ?
> 
> Because too many people still think garbage collection is
> inefficient, and they can do better. 

It's not just what people think, there are a lot scenarios where garbage 
collection is not a problem. I worked many years in the telecom industry 
using C++ and Java... when the hardware got cheap and powerful, we 
started to move a lot of services, protocol stacks, applications and 
code base to Java. Why? Because the development and maintenance over 
several platforms (Windows 32/64 bits, Solaris Intel/Sparc, Linux 
32/64/RHEL 4-8) was ways more simple. How about the performance? Not a 
problem, our application servers were still able to deal with thousands 
of transactions per second without burning the CPUs. Of course, C++ was 
still used, for legacy applications, or for low level layers in some, 
not all, protocol stacks.

Regards

--
Cholo Lennon
Bs.As.
ARG

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

#80751

Siri Cruise <chine.bleu@yahoo.com> wrote:
> In article <sdpojb$aq7$2@dont-email.me>,
>  Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> Because it just works ?
> 
> Because too many people still think garbage collection is 
> inefficient

Because it is.

Or, more precisely, perhaps GC *in itself* is not inefficient, but the
paradigm it's solving has turned out to be.

You see, garbage collection arose primarily from a practical problem in
object-oriented programming, and that problem is: When you dynamically
allocate tons and tons of individual objects, and they refer to each
other in a complicated mesh of references, how do you keep track of all
of this so that each object is properly destroyed once nothing refers to
it, and do it in a manner that's as easy for the programmer as possible,
as efficient and possible, and allows for circular dependencies without
causing leaks?

Thus, an incredible amount of academic and practical research work was
put into garbage collection algorithms and implementations that were as
efficient as possible.

Problem is, it's an efficient solution for a fundamentally inefficient
programming paradigm. It's a solution to something you actually shouldn't
be doing in the first place, in a modern computer system. What is this
thing you shouldn't be doing, you might ask?

Dynamically allocating tons and tons of individual objects. That's what.

In the 1980's and largely the 1990's, when OOP was the absolute king,
dynamically allocating tons of individual objects wasn't really such a
huge problem. CPUs didn't care how you were accessing memory, or how
the execution flow of the program jumped around. Each memory access was
equally slow regardless of which memory address you were using, and
every conditional jump was equally slow regardless of anything.

No longer.

CPUs started introducing memory caches, long instruction pipelines,
predictive branching, and a bunch of other optimizations which
suddenly started caring about how you access memory and how you do
your conditional jumps.

It has turned out that one of the greatest programming paradigms that has
ever existed, object-oriented programming, is also a performance killer
in modern CPUs. This is because OOP, at least the traditional approach
to it, is extremely cache-unfriendly, predictive-branching-unfriendly,
and pipeline-unfriendly, and thus tends to produce inefficient
executables.

For this reason for quite some time now many of the major projects out
there that require extreme performance, such as game engines, have
started moving away from an OOP design to a more data-oriented design
which optimizes for modern CPU architectures much better than OOP does.

And the thing about data-oriented design is that it so happens that it
doesn't benefit nor rely so much on a garbage collector, because you
are trying to avoid random dynamic memory allocations in the first
place (and prefer all data to be neatly in large arrays).

So yes, perhaps garbage collection *in itself* is not inefficient, but it's
fundamentally tied to a programming paradigm that is, and moving away from
that paradigm also lessens the need for GC.

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

#80753

On 28 Jul 2021 10:16, Juha Nieminen wrote:
> Siri Cruise <chine.bleu@yahoo.com> wrote:
>> In article <sdpojb$aq7$2@dont-email.me>,
>>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> Because it just works ?
>>
>> Because too many people still think garbage collection is
>> inefficient
> 
> Because it is.
> 
> Or, more precisely, perhaps GC *in itself* is not inefficient, but the
> paradigm it's solving has turned out to be.
> 
> You see, garbage collection arose primarily from a practical problem in
> object-oriented programming, and that problem is: When you dynamically
> allocate tons and tons of individual objects, and they refer to each
> other in a complicated mesh of references, how do you keep track of all
> of this so that each object is properly destroyed once nothing refers to
> it, and do it in a manner that's as easy for the programmer as possible,
> as efficient and possible, and allows for circular dependencies without
> causing leaks?
> 
> Thus, an incredible amount of academic and practical research work was
> put into garbage collection algorithms and implementations that were as
> efficient as possible.
> 
> Problem is, it's an efficient solution for a fundamentally inefficient
> programming paradigm. It's a solution to something you actually shouldn't
> be doing in the first place, in a modern computer system. What is this
> thing you shouldn't be doing, you might ask?
> 
> Dynamically allocating tons and tons of individual objects. That's what.
> 
> In the 1980's and largely the 1990's, when OOP was the absolute king,
> dynamically allocating tons of individual objects wasn't really such a
> huge problem. CPUs didn't care how you were accessing memory, or how
> the execution flow of the program jumped around. Each memory access was
> equally slow regardless of which memory address you were using, and
> every conditional jump was equally slow regardless of anything.
> 
> No longer.
> 
> CPUs started introducing memory caches, long instruction pipelines,
> predictive branching, and a bunch of other optimizations which
> suddenly started caring about how you access memory and how you do
> your conditional jumps.
> 
> It has turned out that one of the greatest programming paradigms that has
> ever existed, object-oriented programming, is also a performance killer
> in modern CPUs. This is because OOP, at least the traditional approach
> to it, is extremely cache-unfriendly, predictive-branching-unfriendly,
> and pipeline-unfriendly, and thus tends to produce inefficient
> executables.
> 
> For this reason for quite some time now many of the major projects out
> there that require extreme performance, such as game engines, have
> started moving away from an OOP design to a more data-oriented design
> which optimizes for modern CPU architectures much better than OOP does.
> 
> And the thing about data-oriented design is that it so happens that it
> doesn't benefit nor rely so much on a garbage collector, because you
> are trying to avoid random dynamic memory allocations in the first
> place (and prefer all data to be neatly in large arrays).
> 
> So yes, perhaps garbage collection *in itself* is not inefficient, but it's
> fundamentally tied to a programming paradigm that is, and moving away from
> that paradigm also lessens the need for GC.

Very clarifying. I agree with you. I just didn't think of it that way.

- Alf

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

#80754

> On 28 Jul 2021 10:16, Juha Nieminen wrote:

> > In the 1980's and largely the 1990's, when OOP was the absolute king,
> > dynamically allocating tons of individual objects wasn't really such a
> > huge problem. CPUs didn't care how you were accessing memory, or how
> > the execution flow of the program jumped around. Each memory access was
> > equally slow regardless of which memory address you were using, and
> > every conditional jump was equally slow regardless of anything.

So C++ but no OOP?

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

#80755

On 28 Jul 2021 16:53, Siri Cruise wrote:
>> On 28 Jul 2021 10:16, Juha Nieminen wrote:
> 
>>> In the 1980's and largely the 1990's, when OOP was the absolute king,
>>> dynamically allocating tons of individual objects wasn't really such a
>>> huge problem. CPUs didn't care how you were accessing memory, or how
>>> the execution flow of the program jumped around. Each memory access was
>>> equally slow regardless of which memory address you were using, and
>>> every conditional jump was equally slow regardless of anything.
> 
> So C++ but no OOP?
> 


Multi-paradigm. :)

- Alf (Oh, "I like your car"! :-o )

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

#80756

In article <sdsaru$emf$1@dont-email.me>,
 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:

> On 28 Jul 2021 16:53, Siri Cruise wrote:
> >> On 28 Jul 2021 10:16, Juha Nieminen wrote:
> > 
> >>> In the 1980's and largely the 1990's, when OOP was the absolute king,
> >>> dynamically allocating tons of individual objects wasn't really such a
> >>> huge problem. CPUs didn't care how you were accessing memory, or how
> >>> the execution flow of the program jumped around. Each memory access was
> >>> equally slow regardless of which memory address you were using, and
> >>> every conditional jump was equally slow regardless of anything.
> > 
> > So C++ but no OOP?
> > 
> 
> 
> Multi-paradigm. :)

My sql interface returns effectively arrays of unions. I also 
have no deallocation interface. I do have explicit begin/end 
because sql tables really need to have transactions ended or 
aborted in a clear and definite manner.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Doria sockpuppet.                  insults Islam.  Mohammed

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web