Re: C++ sucks for games

From: Mark A. Gibbs (x_gibbsmark_at_rogers.com_x)
Date: 10/27/04 

Date: Tue, 26 Oct 2004 22:18:06 -0400

Hannah Schroeter wrote:

> Or you're just doing a typo-like mistake, as in
>
> class A {
> public:
> explicit A(const std::string& x) : x(x) {}
>
> protected:
> const std::string& x;
> // ^ oops, intention was the same w/o the &
> };
>
> A* make_a()
> {
> return (new A("foo"));
> // oops, temporary std::string gets destroyed before we return,
> // the A object contains a dangling reference
> }
>
> int main()
> {
> std::auto_ptr<A> x(make_a());
> // do something with x
> }
>
> Of course it was just a typo. Just a typo that can be horrendous to
> debug.

you could just as easily create nightmare typo scenarios in any
language, including plain english. that example is plainly a careless
mistake. no one and no language can promise that some idiot won't come
along and do something stupid to muck everything up.

incidently, make_a() should probably return an auto_ptr<A>.

>>references cannot cause memory leaks.
>
> ^ add "alone"
>
> No, but dangling references are easily built.

oh yes, but by following some simple guidelines they can be just as
easily avoided. i honestly cannot remember the last time i had a
dangling reference crop up in my code.

>>in good design, memory is freed by the same entity that allocated it.
>>the use of pointers or references does not invalidate good design. it
>>allows you to if you so choose, and sometimes that's a valid design
>>decision. but if your memory management is scattered and out of control,
>>that's your fault, not any language's.
>
>
> So if you need to pass around things, like
>
> A B
> is created (doesn't exist yet)
> creates x
>
> is created
> ---- pass on x ->
> now needs the x
> is destroyed
> lives on
>
> you have to agree on a discipline of managing x, or you copy it over,
> so A destroys its copy and B manages its own copy. The latter may not
> always be viable, because things might rely on the identity of x.

i said good design. this is horrendous design.

to put it in concrete terms:

    Oven Furnace
  is built (doesn't exist yet)
  contains it's own thermostat
                                            is created
         ----- give thermostat to furnace --->
                                      now needs the thermostat
  is destroyed
                                             lives on
                                    (with the oven's thermostat)

does that make logical sense?

furnace would be free to put the thermostat into any kind of state that
may be invalid within the context of oven, or vice-versa (you set the
oven to 275° and your house ignites).

but let's say for argument's sake that you did have to have a shared
object and that you could not be sure of it's lifetime.
std::tr1::shared_ptr (aka boost::shared_ptr).

> If the pattern how x is transferred or not transferred, you can't just
> say "ok, A creates x, B destroys it always".

again, shared_ptr. but c++ is more suited to a more deterministic
problem domain. vaguely allocating and tossing memory around with no
concept of ownership or responsibility isn't a good idea in tighter
architectures, or even in more expansive architectures where you want
close control of resources. if memory is cheap and plentiful, then sure,
but then c++ may not be the best tool for the job.

> auto_ptr isn't a smart pointer. It's quite dumbass, not even viable
> for containers at all.

of course auto_ptr is a smart pointer, it's just a smart pointer with a
very specific problem domain. it's specifically for the purpose of
transfer of ownership (as i mention above, c++ tends towards more
deterministic programs).

"smart pointer" is a family of solutions, not a specific solution.

boost::scoped_ptr has an even narrower problem domain, but i still find
it occasionally useful - although auto_ptr does the same job and more at
about the same cost.

>>besides, with a garbage collected-only language, you can't practically
>>implement raii, and i think that's a serious flaw.
>
>
> You don't need raii then, as most raii is about memory, and the rest
> can be handled with good macro facilities (see Common Lisp's
> with-open-file for an example) or higher order functions.

memory is only a very, very small part of raii. the first "r" is
resource - and resource can be anything at all. in fact, in my code, i
probably use it most often for synchronization.

no matter what happens, i can be assured that all resources will be
properly released. that is, for any possible code path, including those
that i cannot predict, and including all exceptional code paths (short
of an absolute emergency (ie. crash)), the resource will be properly
cleaned up. and i can know *exactly* when that will happen.

that is not trivial to do, no matter what macros or other tricks you
use. i don't know lisp that well, but i have a hard time seeing this
pattern being easily implemented in any garbage collected environment.
the only way you can do it in java is if you use try-finally blocks
everywhere, and that's just grotesque.

indi

Relevant Pages

  • Re: Motivation for smart pointers
    ... >The RAII (Resource Aquisition Is Initialization) idiom is used here ... RAII model, and which is only partially realted to memory. ... primatives, UI widgets, etc. all can be used with the RAII idiom (and ...
    (comp.lang.cpp)
  • RFC: Memory Controller
    ... We've seen a lot of discussion lately on the memory controller. ... limit the usage of the resource to the specified value. ... with the specified guarantee of resource availability. ...
    (Linux-Kernel)
  • Re: RAM-CPU Singularity
    ... resource to compensate the urgent needs of another kind of resource. ... That's why the original thinkers came up with the cache stuff: ... It's the same with processors and memory. ... I guess you called "virtual memory" the swap space on disk, ...
    (comp.theory)
  • Re: Linux as resilient as BSD, resource hogging?
    ... >> one particular resource, most of them can be used for all resources. ... I did fully implement a memory controlling ulimit (admittedly ... > causes additional paging. ... > *hog* process would be suspended. ...
    (comp.os.linux.security)
  • Re: [ckrm-tech] [RFC][PATCH] UBC: user resource beancounters
    ... kernel memory and virtual memory. ... fair CPU scheduler is not tied to UBC in any regard. ... the infrastructure (for resource management) we ... it is also more logical to have them separate since they ...
    (Linux-Kernel)