3D graphics programmers using Python?

[Alex Martelli]

Erik Max Francis wrote:

> Alex Martelli wrote:
> 
>> Erik Max Francis wrote:
>>
>> > Presuming that's meant to be a _putting_ there, I'm not sure I
>> > understand what it's getting at.  If containers aren't for putting
>> > objects into, what would you put in them?
>> 
>> Pointers or smart pointers to the objects.
> 
> Don't people throw a fit when you talk about containers of pointers in
> comp.lang.c++[.moderated]?  (Smart pointers, fine.  Objects with proper
> copy semantics, fine.  Raw pointers, eep.)

Yes, people DO "throw fits" in such cases, because there are a zillion
possible misuses and misbehaviors connected with "containers of raw
pointers" (and with raw pointers in general, actually) -- dangling
references are quite possible (when the object is destroyed but there
are still pointers to its "ghost" around), anything requiring an
ordering (e.g. a sort of the container) produces junk (comparing
pointers, besides being technically illegal for pointers that do
not point into the same array, gives results that are almost never
as intended by the programmer), etc.

So, I sympathize with the fits.  _However_, there are use cases
which make certain "containers of pointers" perfectly valid -- and
they can in such cases be faster than containers of objects (due
to copy overhead) OR containers of smart pointers (due to the sheer
overhead of the pointers' smarts).  Since C++ (IMHO) is to be used
only when performance matters a LOT, I consider such "optimizations"
to be important -- they cannot be "premature" optimizations, since
by the time I'm recoding something in C++ I _am_ in a quite advanced
stage of optimization anyway;-).

First issue with containers of raw pointers: those containers (in
general), or at least each specific pointer they contain, MUST be
guaranteed to have a lifetime that's a subset of the lifetime of
the objects whose addresses they contain.  I.e. the objects must
be guaranteed to be "long-lived" relative to the containers that
have pointers to them.  This isn't trivial, but isn't any harder
than most other memory management issues in C++, anyway.  Second
issue, you must ensure no comparisons get performed *except* in
a "controlled" way -- e.g. if the objects all live within the same
array, _then_ comparing pointers to them may make sense (if the
order of the objects in the array is semantically meaningful, for
example) -- or, you could perform all comparisons through some
auxiliary function or functor that handles the dereferencing.

Containers of raw pointers in the hands of beginners are a
recipe for disaster.  But then, so is _any_ C++ in the hands
of beginners OR anybody but seriously-experienced C++'ers;-).


Alex