Article of interest: Python pros/cons for the enterprise

[Nicola Musatti]

On Feb 21, 6:31 pm, Paul Boddie <p... at boddie.org.uk> 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