Re: Article of interest: Python pros/cons for the enterprise

On Feb 21, 6:31 pm, Paul Boddie <p...@xxxxxxxxxxxxx> wrote:
[...]
The main reason why C++ has declined in usage is because almost
everything of practical value is optional.

The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.

Meanwhile, those C++
newbies we were talking about are having to deal with decisions that
everyone else can quite happily ignore, knowing that the right choice
has probably already been made for them, where automatic memory
management is probably the right choice for the biggest decision of
them all, as Java demonstrated quite successfully to the hordes of
enterprise programmers (and their managers) at the end of the 1990s.

A choice that is available to C++ programmers too, altough I admit
it's not a common one and does usually require an external library. As
to it being the right choice it's debatable: it took Java something
like ten years to come out with usable GUI applications and, judging
from many articles and postings across the internet memory management
*is* an issue with Java, especially for long running applications.

There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.
Other languages, such as Python and C#, are recognizing this fact and
provide the with/using statement, which serves this purpose but is
definitely more clumsy.

Back to those C++ newbies, then. Of course, none of them pushed into a
C++ project is going to have much say about which memory management
"best practice" is going to be used - the decisions are already set in
stone by the project - and so it's all about coping with the tedious
tracking of "who owns which pointer" and hoping that different
libraries don't have different policies. Taking the quotes out of
order...

Sorry, but although this was probably true in the early 90's that's
not the way it goes in practice nowadays, thanks to automatic
variables, destructors, the standard library containers and smart
pointers.

At least C++ programmers tend to know that memory
must be managed, while newbies in other languages are often lead to
believe - wrongly - that the garbage collector takes care of
everything.

Sure, there are some issues with memory consumption patterns with
various garbage collectors, but the "it's good for you" attitude has
scant justification unless you're dealing with constrained
environments.

It's not just a matter of memory consumption patterns, it's also a
question of explicitly resetting your memory references to ensure that
the GC can reclaim them. This can be less than obvious when complex
data structures and/or callback objects are involved.

And even with people watching the dials in their C++
application, you still get obscene resource misuse, which is why
Firefox eventually consumes over 1GB memory on this desktop. There are
considerably fewer caveats involved with regard to languages with
garbage-collected runtime environments.

Unfortunately C++ by itself cannot ensure that only top programmers
use it ;-)

I seem to remember that Hans Boehm had some interesting observations
about garbage collection myths, especially around performance, but
since the mindset persists in large tracts of the C++ development
landscape that it must somehow be cheating to use a garbage collector,
I suppose we still have a few more years of applications accessing the
wrong memory locations and showing the usual useless backtrace
dialogues for submission to uninterested developers who insisted on
using C++ because "everything else is slow".

Things change. Boehm himself is working for the inclusion of -
optional - garbage collection in the C++ standard.

Cheers,
Nicola Musatti
.

Relevant Pages

  • Re: MFC future?
    ... major desktop applications written in C#. I've only seen a couple in Java. ... > it's the memory management model used in environments like .NET and Java. ... > everything is managed by garbage collection the garbage collector ends up ...
    (microsoft.public.vc.mfc)
  • Re: MFC future?
    ... It seems to me that MS must have had some considerable investment in Java at ... it's the memory management model used in environments like .NET and Java. ... everything is managed by garbage collection the garbage collector ends up ...
    (microsoft.public.vc.mfc)
  • Re: out of memory
    ... it is possible to Manage to write your own custom Managed Memory leak. ... Garbage Collection IS automatic, but unless you put your cans out on the ... the purpose of Memory Management ... A good practice is to put the app first on a staging server and then put it ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
    ... My problem with it is the lack of a garbage collection. ... pretty much have memory bugs, ... Modern GCs are much faster than older ones, ... Concurrent GCs exist, nevermind GCs that play fairly nicely with concurrent application code. ...
    (comp.programming)
  • Re: How come Ada isnt more popular?
    ... manual memory management. ... But for the sake of discussion completeness, you might wish to throw an example of a situation where scoped lifetime will not make it. ... this was *manual* resource management. ... The difference is that in languages with scoped lifetime the lifetime management is a property of the type, whereas the "FP-trick" above is a property of the use-side. ...
    (comp.lang.ada)