> -----Original Message-----
> From: compsci-bounces@???
> [mailto:compsci-bounces@???] On Behalf Of Andy Sy
> Sent: Thursday, May 15, 2008 6:15 AM
> To: True Computer Science Mailing List
> Subject: Re: Steve Yegge on Dynamic Languages
>
> The saying regarding "ad-hoc bug-ridden implementations of
> Lisp appearing in sufficiently complicated C/Fortran programs"
> bears repeating over and over here. If you're going to manage
> memory yourself in the name of optimization, once your system
> becomes big enough, you'll end up with your own implementation
> of a garbage collector anyway and probably a poor one at that.
> (and if you think you can rely on "static analysis" to avoid
> all usage of the heap, you need to be committed... but of course
> it was a nice opportunity for Dean Berris to brandish that term
> to make himself sound smart).
>
> This also reminds me of the idea of self-freeing C++ classes
> being touted as a superior alternative to using GCs... we'll
> let the marketplace decide how good or daft an idea this is...
>
Actually, the marketplace has decided, and the RAII pattern that is
inherent in C++ because of the use of scope-based resolution and the use
of the stack instead of the heap for storing data as much as possible
(and in some cases, the data segment for static variables) has weeded
out every other approach for doing explicit memory management. I'm
working on a project with already some thousands of lines of code in C++
what doesn't do explicit memory management, and relies on a mix of the
standard and Boost.Pool allocators as well as smart pointers (Boost's
shared pointer, which will be made part of the TR1 as the reference
implementation) that doesn't make me worry about managing memory myself.
And I am not alone in this: Adobe, Microsoft, and Google have been using
C++ internally to deliver products and services that benefit from the
viability of C++ in delivering performance-critical software (Adobe
Photoshop, Microsoft Excel, etc.) and services (Google's MapReduce).
As far as explicit memory management is concerned, this is the same
reason why C++'s STL provides you with containers which you can use to
abstract the memory management aspect and just use the ADT's in your
application without having to worry about memory management explicitly.
Now when it comes to optimizing these memory management routines after
profiling and seeing the hotspots, it's just a matter of: 1)
re-organizing your code by hand to write faster algorithms and more
space/computation efficient operations or 2) using a specialized memory
allocator for your particular use case. If you're still doing manual
memory management in C++, then it should only be because you're writing
your own allocator; otherwise, it's a case of PEBKAC.
And no, there is no need for a garbage collector in C++ especially if
you know what you're doing.
Of course, it also depends on what market you're looking at. If you're
thinking the web market, then everybody will benefit from advances in
C++ anyway, because even C will benefit from it, and thus the
implementation of the VM's, interpreters, and compilers, will become
easier to implement and more efficient in multi/many-core platforms.
There's also the improved memory model, support for lambda's, among many
other standard library and language additions coming out (auto,
decltype, typeof, etc.). Oh, Java's VM is in C/C++, the CLR is written
in C/C++, Python/PHP/Ruby(?) is written in C and can be extended with
C++, your DB is written in C/C++, your web server is written in C/C++,
your web browser (where you usually run your Javascript) is also written
in C/C++... So even if you don't directly use C++, you're indirectly
affected by advancements in it (and the compilers available).
So even if you absolutely hate C++ because of your personal
preferences/limitations, it inevitably actually shapes your world as of
the moment.
--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmberris@???>
+639287291459
______________________________________________________
True Computer Science Mailing List
compsci@??? (#CompSci @ irc.free.net.ph)
http://lists.free.net.ph/mailman/listinfo/compsci
Searchable Archives: http://archives.free.net.ph
