Re: [Mesa3d-dev] C++ in Mesa?

[Ian R. <id...@fr...>]

On Tue, Jan 06, 2009 at 09:00:48PM +0000, keithw wrote:

> Unfortunately LLVM is C++ so it's harder to argue that we should exclude
> it.  But I still think we should, mainly because C++ usage always
> spirals out of control into the nastiest steaming pile of poo.
> Everybody always says "oh, of course it can be bad, but we'll stick to a
> lovely subset that is purest gold, it'll make life so good, and we'll
> never, never up the dosage".  

I understand that sentiment.  That's the main reason I haven't used it
(much) since the mid-90s.  There are a couple ways that we could
combat this, but I'm not sure how effective they would be.  The most
important thing would be to document the accepted sub-set.  Folks
could then reasonably review patches and NAK the ones that violate the
rules.  Given the amount of review most commits get, this seems
unlikely.  I suspect we could also create a pre-commit hook that could
detect at least some of the fobidden usages.

> But it's a drug that addles the mind, and like it or not, once you start
> you're hooked.  One day it's a little operator overloading, the next
> it's some eminently reasonable STL usage, and before you know it,
> there's all sorts of shit all over the place and no way to escape.

Heh...that sounds like exactly the way the C++ standard was developed.
:)

> Ultimately, what matters is containment.  If the usage is restricted to
> the GLSL compiler module, and that module has a clean interface which is
> expressed in pure C functions and structs, then nobody can complain too
> much.  We've successfully ignored some nasty stuff down there before.

The whole thing may be moot at this point.  I dug a bit deeper
yesterday, and I'm not sure the benefit of converting my existing work
to C++ would outweigh the effort required to do it.

The big problem is that I use a lot of structures with embedded
variable-length arrays.  I don't know of a way to handle that in a C++
class.  For example:

struct glsl_tree_expression {
    struct glsl_tree_base base;    /**< Base class. */

    glsl_tree *operands[1];
};

I guess that could be handled by overloading new for that class, but I
think I'd rather slam my thumb in a car door.